Understanding Salesforce Integration Patterns with examples

Hello Friends! Today, we are going to discuss the six integration patterns in Salesforce. These patterns are proposed by Salesforce for most of the integration scenarios with the Salesforce ecosystem. 

All these patterns are nothing but guidelines for building fast, scalable, reliable, and secure integrations. They will guide you on when to use which API from the Salesforce platform. They all discussed considering Salesforce as a primary system.

Having an understanding of these patterns is really very helpful no matter what is your role in the Salesforce ohana. I will explain all the patterns with simple examples.

Before we start, let us understand the different types, timings, and sources of integrations.


It can be either Salesforce or a third-party remote system or a middleware.


  1. Process Integration - It is used when two systems are connected together as part of the functional flow. For example, Salesforce creates a sales order and it is sent to the delivery system as soon as payment is completed.

  2. Dara Integration - It is used when two systems are connected to share information and synchronize information. For example, Salesforce pushes data to a remote database for backup.

  3. Virtual Integration - It is used when Salesforce interacts with the data that is stored on the remote system. Data is not stored in Salesforce, but we can read/write/update it in Salesforce using Virtualization. For example, external objects in Salesforce.


  1. Synchronous - This is near-real-time integration and the requester is blocked/kept waiting until the response is received. For example, When a REST call is made from the Apex it waits until the response is received, and the response is received in the same transaction. 

  2. Asynchronous - In this integration, the requester is not blocked/kept waiting for the response, requests are kept in a queue and processed one by one. The requester can simply submit the data and forget. 

Remote Process Invocation—Request and Reply

Source: Salesforce
Type: Process Integration 
Timing: Synchronous 

We use this pattern when Salesforce calls a remote system(third party) and waits until the response is received from there. For example. calling a remote service at the click of a button to get data. You can use External services or Apex Rest API call for this pattern. 

You need to consider the salesforce transaction limitations in this pattern, for example, waiting time for the response, and maximum allowed CPU time for a transaction.

Remote Process Invocation—Fire and Forget

Source: Salesforce
Type: Process Integration/Data Integration 
Timing: Asynchronous 

We use this pattern when Salesforce calls a remote system but does not wait for the response. The remote process responds back with an acknowledgment whenever the request is processed, there can be a significant delay between request and response of this pattern. 

So basically Salesforce does not have to worry about the request unless the remote system sends the response back, it can be either success or failure.

The best example of this pattern is the workflow/flow-driven outbound messages. Another example is platform events, like Salesforce does not have to wait once the event is fired.

The Fire and Forget pattern often comes with guaranteed delivery of the message, because of its queue and retry mechanisms. Usually, there is a middleware that handles the queue and retries. The requests are not removed from the queue unless they are not served.

Batch Data Synchronization

Source: Salesforce/Remote System
Type: Data Integration 
Timing: Synchronous/Asynchronous 

Use this pattern to import or export a large amount of data to/from Salesforce. For example, you want to load thousands/millions of records into salesforce. Another scenario is to sync all data updates between the two systems to avoid data integrity.

You can use Change Data Capture to send data upd ates to third-party systems. ETL tools like data loader, and Jitterbit can be used to import or export the data. Bulk APIs can also be used for data sync.

Other way is Remote Call In from a remote system or Salesforce.

Remote Call-In

Source: Remote System
Type: Data Integration/Process Integration
Timing: Synchronous/Asynchronous 

We use this pattern when a remote system wants to create, read, update Salesforce data, send platform events to Salesforce, or create/update/delete Salesforce metadata.

You can use Salesforce's standard SObject APIs, Apex SOAP/Rest services, platform events, Bulk APIs, tooling APIs, etc. 

UI Update Based on Data Changes

Source: Salesforce/Remote System
Type: Data Integration/Process Integration
Timing: Asynchronous 

When you want to update data based on the occurrence of an event either in Salesforce or a remote system then this pattern is used. 

For example, imagine a customer service agent is on the call with the customer and they have the customer's order record open. So when the customer makes from your E-Commerce website, the payment for the order while being on the call.

The agent does not have to refresh the order page to see the updated payment status. Platform Events/Streaming APIs can be used here to auto-update the page as soon as the payment is made from the E-Commerce website.

Data Virtualization

Source: Salesforce
Type: Data Integration
Timing: Synchronous 

Many times you don't want to store all the data from the remote system in Salesforce. In these scenarios, you can use data virtualization. Basically, the data is not stored in Salesforce but you can still read/update/delete data from Salesforce UI, through Salesforce Connect.

Salesforce Connect only creates object metadata in Salesforce and connects the remote system data through OData protocol and displays the data on Salesforce UI where you can see and make changes to data. 

Another approach for virtualization is to build a custom UI with Lightning Components or VF. You can write apex code to fetch/update data to work with Lightning Components/VF.

The best part of Data Virtualization is that you can access live data from a remote system in Salesforce and data is not stored in Salesforce.

Final words

I hope you got some insights on Salesforce Integration patterns, and that now you understand when to use what. In the next part, we will see all these patterns in detail.

Thanks for reading!
No comments :
Post a Comment

Hi there, comments on this site are moderated, you might need to wait until your comment is published. Spam and promotions will be deleted. Sorry for the inconvenience but we have moderated the comments for the safety of this website users. If you have any concern, or if you are not able to comment for some reason, email us at rahul@forcetrails.com