Skip to Content
Product Information
Author's profile photo David Honan

The power of the Salesforce Sales Cloud Connector in Open Connectors

In this blog you will learn about what makes the Salesforce Sales Cloud Connector in Open Connectors so unique and powerful, and how it will save you a lot of custom integration work when integrating to Salesforce.

You’d think that a cloud based company like Salesforce would set the standard with respect to their API specification – and in may ways they do – but like every other cloud application, Salesforce has its own set of API nuances.

What’s unique about the Salesforce Sales Cloud Connector?

First: All of the Connectors within OCN standardize “GET” resources to GET /<resourceName> with the response being the full set of fields for that object returned in the JSON payload. This standardization makes GET /<resourceName> consistent and predictable across every Connector in OCN.

So, for the Salesforce Connector, a few examples of the available GET resources are:

And the expectation is that when those resources are called, ALL (non-null) fields associated with the object are returned in the response JSON payload.

However, the native Salesforce API specification requires that the set of fields that you want returned for a given object be specified in their GET /sobject resource call. 

Issue1: The Salesforce native API does not allow for a GET /contacts where all the fields for a contact are eligible to be returned.

Issue2: The Salesforce native API does not allow for an open query like select * from contact; the specific fields names are required as part of the select request.

Thus, the Salesforce Sales Cloud Connector has to accommodate and automatically determine the full set of fields to return from a GET call.

To solve this, Open Connectors, via the Salesforce Connector, automatically introspects the metadata for the desired <objectName> and thus gets the full list of fields available for that object – including any associated custom fields. The Connector assembles the query based on the Salesforce standard – specifying the full set of field names – and thus can return the full set of possible fields from a GET /<objectName> request.

What the Connector does:

  1. The Salesforce Sales Cloud Connector automatically makes two requests for every GET /<objectName> request to Salesforce – standardizing so that the developer using the Open Connectors API doesn’t have to code this uniquely to support a Salesforce Sales Cloud integration.
  2. If there is a custom field added to an object, the GET resources for the Connector will return those automatically, eliminating code changes that are normally required to return those when integrating directly using the native Salesforce Sales Cloud API.

Example of GET /contacts in Open Connectors:

GET /contacts returns the full payload of native fields directly from Salesforce. The Connector is actually making two calls in order to standardize the GET /contacts call, and return all possible fields as JSON (that have values):

Second: The bulk data resources in the Salesforce Sales Cloud Connector makes up for file size limits imposed by Salesforce – removing the burden of “chunking” large bulk files in your integrations.

This is a really handy feature that saves time and puts the onus of securely managing large files on Open Connectors.

Issue: The Salesforce Sales Cloud API specification requires when using their native bulk (aka batch) API resources, that the upload is done in batches of <= 10,000 records. Thus, if an integration requires batches of greater than this amount the developer will need to put the required code in place to split the data into chunks of <= 10,000 records and batch load each chunk individually. This can get complex requiring multithreading, handling errors, and so forth.

What the Connector Does:

  1. To solve this, Open Connectors automatically splits the file and handles the multiple batch requests via the Salesforce API resources. For example, if the bulk upload request is for 100,000 records, Open Connectors will chunk it into sets of 10,000 records, multithreading each as separate requests to the Salesforce batch API resources.

Handling large bulk uploads via the Salesforce Sales Cloud Connector eliminates the need for a developer to compensate and code a framework to handle the required file splitting based on the limits imposed by the native Salesforce Sales Cloud native APIs.

Using the standardized Open Connectors Bulk API resources also enforces encryption and meets data compliance requirements as the chunked file records are encrypted and are auto-deleted when the request is completed (treated as transient data).

Tech Hints for using the Salesforce Connector’s /bulk resources:

  1. Consider using the Bulk API if you are managing over 2000 records.
  2. The Salesforce bulk chunking mechanism allows you to use bulk on large data sets without limitations. If you use an orderBy clause, chunking is disabled. If chunking is enabled, it may take longer to get all the data. Also, be aware that Salesforce has daily upload and download limits.
  3. If you encounter record lock issues when performing bulk uploads, you can try serial mode instead of the default parallel node. See the Salesforce documentation topic General Guidelines for Data Loads for more information about parallel and serial modes. To switch to serial mode pass “concurrency”:”serial” in the request metadata.

Third: If you are using the Salesforce Connector to retrieve events from Salesforce, you have two options: 1) Use Salesforce’s webhooks or 2) Use the Connector’s polling framework to query for changes to objects in Salesforce.

Issue: To enable events in Salesforce, your Customer’s Salesforce Admin will need to add in Apex code to generate the webhooks. That is not always an option depending on your customer’s security restrictions, but regardless, it does require code “intervention” and is not automated.

What the Connector does:

  1. The Salesforce Sales Cloud Connector provides a choice – use Salesforce’s webhooks or use the polling framework that it has built in, and which will also generate a webhook back to your application.

Thus, if automation is critical for your use case and you’ll be creating Salesforce Connector instances using Open Connectors’ APIs, then using the poller capability is nice option.

Note that when the poller queries and if finds changes to the requested objects since it last polled, it will send a webhook to the URL of your choice! So, in a way, the Connector “webhookifies” the Salesforce API without the hassle of coding APEX into your customer’s Salesforce account instance. Handy!

In closing, the Salesforce Sales Cloud Connector in Open Connectors adds value over and above the native Salesforce API specifications. Depending on your use case, it will save you time vs. writing custom code directly to Salesforce’s API specification AND it will be consistent with how the other 150+ connectors in Open Connectors work.

More blogs coming soon! Next, I’ll step you through how to build your own Connectors in OCN, complete with videos.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Wallner
      Peter Wallner

      Hello David

      So this connector is available in the "Open Connectors" which is a Cloud Environment. Is that correct?

      Is that connector also available for SAP PO (on premise)? Or do I have to go with the REST adapter or 3rd party adapter (Advantco)?

      Thank you,

      Author's profile photo David Honan
      David Honan
      Blog Post Author

      Hello Peter,

      Yes, the Salesforce Sales Cloud (and others like Sales force Service Cloud) are available via Open Connectors and also yes, OCN is cloud based.

      You can link to it directly via its REST APIs from anywhere including on prem solutions assuming you have cloud service access from that on prem or private cloud environment.

      Think of it as instead of integrating directly to SFDC via their API, you instead use OCN's Connector because of the uniformity of the REST API along with the additional features provided by the Connector (as mentioned in the blog).


      Author's profile photo Tom Dhooghe
      Tom Dhooghe

      Hi David,

      Appreciate the write-up and the clarification here. The related question I have is whether you know which API at SF-side the Open Connector will actually use? Is it the REST version or the SOAP version of the Salesforce API? If the latter, is is the Enterprise or Partner version or is that distinction not relevant here?

      Edit: took another look and seems like it's (rather obviously :)) the REST one given that you talk about SF's internal GET operation as well. I guess conclusion is that the SF Open Connectors are always using the REST API only?


      Kind regards,


      Author's profile photo Anirban Mallick
      Anirban Mallick

      Hi David,

      Thank you for this great blog. I'm currently working on a scenario where we want to send data to a custom SFDC endpoint. Can you please share any insight how we can consume custom endpoint in the Open Connector?