- Almost every Salesforce customer ends up with a fully custom data schema. Customers commonly add new fields, rename standard labels, and create entirely new record types beyond defaults like Lead, Contact, and Account.
- Custom fields and objects carry a __c suffix that standard ones never have. This naming convention is the quickest way to distinguish custom Salesforce elements when mapping fields for an integration.
- Third-party libraries like jsforce abstract away Salesforce's dozen-plus APIs. Rather than manually choosing between SOAP, REST, GraphQL, or gRPC, a library like jsforce automatically routes each request to the right API.
- Salesforce webhooks require two separate pieces: an outbound message and a workflow rule. The message defines what data to send, while the rule defines what triggering event fires it – both must be configured together, or the webhook won't work.
- Salesforce's newer Pub/Sub API offers a messaging alternative, but isn't replacing outbound messages yet. It follows a pattern similar to Google Cloud Pub/Sub, though the older message-and-rule approach remains the primary, proven method for now.
Salesforce, the original SaaS app, has several APIs for developers to use with integrations. Developers who have been working with Salesforce for a long time are often most familiar with the SOAP API, but Salesforce now includes REST, GraphQL, and gRPC APIs.
We are visiting again with Taylor Reece, a Developer Advocate at Prismatic, to discuss some tips and tricks for developers who need to work with Salesforce APIs for integrations.
Bru: Taylor, Salesforce has been around a while, and its flexibility has undoubtedly been a factor in its longevity. How does that flexibility work on the data end of things?
Taylor: Sure. You can customize Salesforce data structures like crazy. The system comes with a number of standard record types, such as Lead, Contact, and Account.
But, few Salesforce customers stick with those standard record types or even the standard fields.
Instead, they'll add any number of new fields to existing record types and even add completely new record types to the schema. They may even change all the labels on standard fields.
As you might imagine, just about every Salesforce customer ends up with a custom schema. It makes things really sticky since a customer can conceivably store just about anything in Salesforce, but it creates a fair amount of work for the devs who need to integrate with Salesforce.
Bru: Custom objects and fields in systems are often treated as second-class items in terms of accessibility. How does Salesforce handle them?
Taylor: In general, Salesforce makes custom record types (objects) and fields automatically accessible via its APIs. So, the data is there and not hidden via some special, convoluted process.
The key to working with the Salesforce data schema is to manage the field mapping. This process goes something like this:
- Select the name of the object (example: Leads).
- View all the fields for the object (including custom).
- Map the field (example: "Lead FirstName__c" to whatever you need).
The simple thing to remember here is that standard objects and fields in Salesforce don't have the double-underscore c suffix, but every custom object and field has that suffix.
Bru: OK. Let's talk a bit about the different Salesforce APIs. What do devs need to know about them?
Taylor: Certainly. Salesforce has a dozen or so APIs. And, if you want to, you can access them natively via SOAP, REST, GraphQL, or gRPC. In many cases, you can use SOQL (Salesforce Object Query Language) to build specific queries against the data.
But that's not usually the most efficient approach to using Salesforce APIs with integrations. Instead, you should use third-party libraries (such as jsforce).
These libraries abstract the Salesforce APIs to the point where you don't need to know exactly which API you'll be hitting with a specific request. Instead, the library brokers that request, sending it to the right API with the right data format.
Bru: Nice. That simplifies something that otherwise appears quite complicated.
Taylor: Yes, it really does. We used jsforce to build Prismatic's Salesforce connector. Without that, it could have easily been an order of magnitude more effort to get everything set up.
On the backend, we primarily connect to Salesforce with jsforce via the GraphQL and REST APIs, but the nice thing is that I don't have to know or care what goes into a given GET or POST since jsforce handles them.
Bru: Let's look at a recurring topic for these API discussions: webhooks. What is special about webhooks for Salesforce APIs?
Taylor: Well, Salesforce definitely has its own way of handling webhooks. The first thing to know is that when something happens in Salesforce, instead of alerting one thing (as is the case with most webhooks), you need two separate things. These are the outbound message and the workflow rule. We'll call them the message and the rule to make things simple.
Now, into the details. The message declares the object and field names (a manifest, if you will) for the data to be sent. For example, you might specify a message with the accounts object with the corresponding ID and annual_revenue fields.
The rule defines (for our example), "When the account object is updated, send the message." The rule doesn't know anything except that the notification event occurred. But, when the rule runs, the message is sent to the webhook endpoint.
So, for Salesforce, you need to remember to set up both pieces (the message and the rule) for every webhook, or your data won't be sent when needed.
Bru: That sounds manageable overall. Is this for all Salesforce webhooks, or is there another approach that devs could use?
Taylor: Right now, this is the primary approach that Salesforce uses for webhooks. However, Salesforce recently implemented an API just for messaging: the Pub/Sub API. We have yet to work with this in any detail, but it seems to follow a pattern similar to what Google implemented for its Cloud Pub/Sub functionality.
For now, we will stick with the tried-and-true approach to webhooks using the outbound message and rule. However, I think we'll likely implement the Pub/Sub functionality for our Salesforce connector in the not-too-distant future – as long as those updates make sense for our customers. We won't, however, be removing our current webhook functionality.
Bru: Excellent. Taylor, thank you for sharing your knowledge of Salesforce APIs.
Schedule a demo to see how Prismatic makes it easier to build integrations connecting your app to Salesforce and then deploy and manage them at scale while providing an in-app integration UX for your customers via the white-label marketplace and embedded workflow builder.
