Our forward-looking statement applies to roadmap projections.

Roadmap corresponds to August 2024 projections.

Guide Overview

There are a multitude of ways to access, synchronize, and share data between Salesforce and external systems. But not every tool is right for your particular project. This guide walks through the landscape of data integration tools available from Salesforce. It also offers recommendations for the tools (or combinations of tools) that are most appropriate given a particular use case, as well as guidance on tools to avoid for specific scenarios.

This decision guide focuses on data-level integrations involving Salesforce. Specifically, it covers the following data integration use cases:

• Salesforce to external systems
• External systems to Salesforce
• Salesforce organization to Salesforce organization

We know that these are only a subset of the integration challenges that Salesforce Architects face, so we will be following up this piece with additional decision guides focused on event-driven integration, building effective customer- or employee-facing workflows using process integration, and more. Lastly, it’s important to note that many of the tools and approaches covered in this guide are also capable of solving integration challenges across the wider enterprise — but such uses are beyond the scope of this guide.

Key Takeaways

• Prefer approaches that avoid unnecessary data replication. Unless the data absolutely needs to reside in Salesforce, consider data virtualization with Salesforce Connect instead. More data in your organization ultimately leads to larger data volumes, which can adversely affect performance and add technical debt. If your data already resides in Salesforce and you need it in an external system, avoid copying it to an external system unless absolutely necessary. Instead, have the external system access the data via the Salesforce APIs.
• If MuleSoft or another Enterprise Service Bus (ESB) or Extract-Transform-Load (ETL) solution is part of your existing landscape, you should use it where possible. Because these tools are purpose-built to help support data migration and transformation, they often have powerful capabilities that enable you to reuse integrations across the enterprise, maintain stronger governance, and centralize management of integrations. In this guide, anywhere MuleSoft Anypoint is recommended, consider whether your existing ESB/ETL solution will suffice.
• Cross-Org and Multi-Org approaches are changing. Data Cloud and MuleSoft should be the preferred technologies for these use cases. To combine customer data from many sources into a harmonized data store, use Data Cloud. For other scenarios in which data needs to be moved between orgs, consider Mulesoft Anypoint.
• Use caution if you choose to build with Outbound Messaging. Salesforce will continue supporting Outbound Messaging within current functional capacities, but does not plan on making further investments in this technology.

Common Considerations For Choosing Data Integration Tools

Before diving into the data integration tools available, it’s important to keep a few common considerations in mind when choosing a tool. As is typical with architecture, there is no prescriptive answer to every business challenge. If you’ve uttered the words “it depends” when making integration choices, then you’re in the the right place.

Overview of Data Integration Tools

Here is a high-level overview of the tools available for data integration and some considerations to start evaluating each option. In the following sections, this guide includes in-depth use case examples and more details about the capabilities of these tools.

• Available: works well for most use cases
• Not Ideal: possible but consider an alternative tool
• Not Available: no plans to support in the next twelve months

Other tools that may be involved in moving data into and out of Salesforce:

There are other tools that may support some aspects of a data-layer integration, but should not be considered a primary means of solving integration problems. Let’s take a quick look at these tools now, and why it is you won’t see these tools mentioned in more detail throughout this guide.

Lightning Web Components are typically used for process integrations, but they can make callouts using JavaScript functionality, so data could be involved in these transactions.

Salesforce Flow can be used to orchestrate external callouts with External Services or Apex Actions. Salesforce Flow by itself is not considered a standalone data integration tool.

Data Import Wizard and Data Loader can be used to synchronize, import, and migrate data. While Data Loader commands can also be scripted to automate the import and export of data, the command-line interface is for Windows only and neither of these tools is a recommended base for a data integration strategy. They should, instead, complement your data stewardship and maintenance strategy.

Salesforce CLI data commands can be used to manipulate records in your org. Commands are available to help you import and export data with the Bulk API and SObject Tree Save API, and perform simple CRUD operations on individual records with the REST API. The Salesforce CLI by itself is not considered a standalone data integration tool.

OmniStudio Data Mapper can be used as a declarative ETL tool to move data between Salesforce objects and JSON data structures. While a REST interface is automatically created for each Data Mapper interface, providing a declarative way to move data from external systems to Salesforce objects, Data Mapper standalone is not a recommended base for a data integration strategy. Data Mapper actions are available in OmniStudio Integration Procedures.

Dataloader.io is another data loader tool for Salesforce powered by MuleSoft’s Anypoint Platform allowing you to quickly and securely import, export and delete unlimited amounts of data for your enterprise. Dataloader.io is not a recommended base for a data integration strategy.

Salesforce to External Systems (Outbound Integration)

Low-Code Tools for Outbound Integrations from Salesforce

Sample Solutions for Outbound Integrations from Salesforce Using Low-Code Tools

Scenario: When opportunities are won, an order for the associated products needs to be created in the company’s ERP system or order management system.

Change Data Capture As Opportunity records are updated, Change Data Capture publishes change events that contain the updates to the objects. The change events are consumed on the customer’s side over a CometD connection (or via a MuleSoft connector) and used to update the customer’s ERP or order management system. Change events can be enriched to always include external record IDs or other data from the object (such as region) that are needed for the integration. Change event streams for multiple objects can be combined into channels for simplified subscription and stream processing (so you can subscribe to and process one stream instead of many).

External Services If you have a web service that supports the OpenAPI 2.0 or 3.0 specification, you can expose the operations and services as an External Service within Salesforce. The API operations (for example create order) can be called as an Invocable Action in a flow built with Flow Builder when the stage of the opportunity is changed to "Won".

Heroku Connect Heroku Connect is typically used to keep a Heroku Postgres Database and Salesforce in sync. If the customer uses Heroku Postgres as their source-of-truth transactional store, then you can sync the records and the changes from Salesforce to Heroku Postgres using Heroku Connect. From there, you can use Heroku Streaming Connectors to publish those changes to Apache Kafka and send them as events to downstream applications, including the ERP or order management system.

MuleSoft Composer Mulesoft Composer enables practitioners without developer skills to easily build integrations. Composer flows can trigger on events or on a schedule. Flows execute the logic and steps required for the integration, connecting to Salesforce and third-party systems via connectors. Through the Salesforce connector, you can configure a trigger/event on the Opportunity object (specifically when the stage of the opportunity is changed to "Won") to initiate the flow. The flow can read the Opportunity details and obtain the related ordered items via the Salesforce connector, and via the NetSuite connector create an order in the NetSuite ERP. Authentication against these systems is typically done via OAuth. There are no limits on the number of flows that can be triggered or on outbound transactions aside from the limitations imposed by the integrated systems (in this example, Salesforce and NetSuite).

OmniStudio Integration Procedure When an order is submitted, the Omniscript orchestrating the process can post the order details to an ERP or MuleSoft connector. The post can be executed either directly by the Omniscript (client-side) or indirectly via an Integration Procedure (server-side). If the ERP system throws a validation error, the Omniscript UI should notify the user, and if necessary, translate and contextualize the error for the user.

Salesforce Connect/External Objects You can create a record-triggered flow in Salesforce that inserts a record into the related external object(s) when the stage of the opportunity is changed to “Won”. Since this is a mixed transaction, to avoid errors add a pause element for zero seconds between the Opportunity update and the related external object insert(s) so that you close one transaction context before you start a new one.

Hybrid Tools for Outbound Integrations from Salesforce

Sample Solutions for Outbound Integrations from Salesforce Using Hybrid Tools

Scenario: When opportunities are won, an order for the associated products need to be created in the company’s ERP or order management system.

Apex Actions A record-triggered flow based on the opportunity state can be triggered automatically when an opportunity is won. The flow executes an invocable action that uses an external callout to submit the order to the order management system or ERP solution. High-volume submissions and multisite orders are handled by Apex batch and queue mechanisms.

Generic Events (Legacy) While Generic Events provide the flexibility of a custom payload, they are not ideal for this scenario because they are not tied to Salesforce data changes and are only publishable via the REST API. To meet the requirements of this scenario, start by creating a new StreamingChannel object in the Salesforce UI, via Apex or any data API, so the external service can subscribe to this custom event using CometD. Next, create an invocable Apex class that can be called from a Salesforce Flow to initiate the callout via the REST API publishing the event and sending a notification to the subscriber. With a custom payload supported by Generic Events, you can include all the data required to create the records in the external system with a single message.

Outbound Messaging After setting up outbound messaging, you can define a workflow rule triggered by the opportunity update to send a SOAP message over HTTP(S) to a specified endpoint URL hosting the listener. The message will contain the fields specified when the outbound message was created. If the information in the object changes after the notification is queued, but before it is sent, only the updated information will be delivered and messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue. If the ERP system requires additional data, you can pass the sessionId in outbound messages so the external system can make a callback request.

Platform Events You can define a platform event that includes the custom payload with the data required to create the records in the external system. Because Platform Events are not auto-published upon record change, you would need to publish the event via Apex, Salesforce Flow or Process Builder when the stage of the opportunity is changed to "Won". An external service listens to the platform event channel using CometD (or a MuleSoft connector) and creates the appropriate records in the external system.

PushTopic (Legacy) Via Apex, you can define a PushTopic, including a custom query that will publish an event when the stage of the opportunity is changed to "Won" or when CloseDate changes. Individual PushTopics do not support relationships in the query, but since the ID must be part of the selected fields list, the external subscriber can make a remote call into Salesforce to retrieve the products to be created in the ERP or order management system. Alternatively, you can subscribe to multiple objects at the same time via bulk subscriptions to send Opportunity and Product updates together.

Salesforce Connect/External Objects (with custom Apex adapters) A solution based on Salesforce Connect/External Objects wouldn't be as applicable in a use case that purely requires data synchronization. However, if users within Salesforce need to see (and potentially interact with) data from the external system, and the data cannot be replicated in Salesforce, then this solution may apply. If the ERP or order management system does not support OData or GraphQL protocols, then the development team can use the Apex Connector Framework to write Apex classes that handle communication with the external system via a supported protocol.

Pro-Code Tools for Outbound Integrations from Salesforce

Sample Solutions for Outbound Integrations from Salesforce Using Pro-Code Tools

Scenario: When opportunities are won, an order for the associated products need to be created in the company’s ERP or order management system.

Custom Apex You can create an Apex trigger and trigger handler(s) on the Opportunity that makes a callout to the ERP or order manage system when the stage of the opportunity is changed to "Won". Note that if you are making callouts from a trigger or after performing a DML operation, you must use a method annotated as future or queueable. A callout in a trigger would hold the database connection open for the lifetime of the callout. All Apex code is bound by Apex Governor and API Limits, which are revised on an ongoing basis.

External Services If the company’s external ERP or order management system are defined via an OpenAPI specification the callouts to those services that are performed in the future method or queueable job could be simplified. The registered external services can be called directly from Apex without needing to write boilerplate code. In the case of the example, the callout to create the order can be handled by the external service.

MuleSoft Anypoint MuleSoft Anypoint provides enterprise-grade API management. MuleSoft Anypoint can create APIs to enable read (and/or write) access to data for Salesforce and many other enterprise systems. There are many prebuilt connectors available to simplify implementation, and companies can create and publish their own connectors as well. These APIs can be deployed in Anypoint with flexible security policies, supporting centralized management and governance. There are no restrictions on volume of transactions, as long as the API has been properly sized for its peak utilization (as measured in vCores).

External Systems Data to Salesforce (Inbound Integration)

Low-Code Tools for Inbound Integrations to Salesforce

Sample Solutions for Inbound Integrations from Salesforce Using Low-Code Tools

Scenario: A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

Heroku Connect Heroku Connect is typically used to keep a Heroku Postgres Database and Salesforce in sync. Unless the ERP system uses Heroku Postgres as its transaction store, this use case is not possible. If it does use Heroku Postgres, then changes made in the Postgres tables can be synced to objects in Salesforce using Heroku Connect.

MuleSoft Composer MuleSoft Composer enables practitioners without developer skills to easily build integrations. You can use MuleSoft Composer to set up a trigger on changes to specific objects (such as a contact) on the ERP system (currently NetSuite is available). When a change is made, the trigger kicks off a Composer flow that can perform downstream activities involving Salesforce (one or multiple different Salesforce organizations) or any other third-party system for which Composer has a connector available. Authentication against these systems is typically done via OAuth.

OmniStudio Integration Procedure After the ERP system updates the contact record, an OmniStudio Integration Procedure with a Data Mapper Load Action and a Response Action can be called via the REST API generated by Data Mapper. First, a Data Mapper Load action sends a JSON or XML payload, which is used to upsert the contact records based on an External ID field or through an Upsert Key. If a simple response in JSON is all that is expected then a Response Action can send back any relevant information from the previous actions to indicate success or failure. If the ERP system expects a specific response then a Data Mapper Transform or Extract Action can be used to generate a JSON or XML response with additional features to declaratively include data that was generated in triggers by the contact record update. The main challenge with this scenario is concurrency: Multiple calls to update the same contact record concurrently will cause issues as the API exists directly in Salesforce.

Salesforce Connect / External Objects Salesforce Connect and external objects are not recommended for this use case, as the scenario specifically requires data replication in Salesforce. If you have a pre-existing Salesforce Connect integration built to the ERP, you could configure the OData 4.0 connector to support external change data capture if the ERP can support change data capture. You would need to do further configuration in Salesforce to subscribe to the change stream from the ERP, using Pub/Sub API.

Hybrid Tools for Inbound Integrations to Salesforce

Sample Solutions for Inbound Integrations from Salesforce Using Hybrid Tools

Scenario: A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

Platform Events Custom code in an external system publishes a Platform Event when the contact record is updated in the ERP. A trigger, Process or Flow in Salesforce can subscribe to the platform event, and update the corresponding Salesforce object(s) when an event is processed. The Platform Event may function simply as a signal that a change happened in the customer’s ERP system without containing any data, or it may contain the actual data needed to update the Salesforce object.

Salesforce Connect/External Objects (with custom Apex adapters) This solution isn't applicable in a use case that requires data replication. This solution would be applicable if you needed users in Salesforce to see information from an external system that should not or cannot be replicated in Salesforce, and the external system cannot support standard protocols like OData or GraphQL. See Sample Solutions for Outbound Integrations from Salesforce Using Hybrid Tools for an example use case for an Apex custom adapter.

Pro-Code Tools for Inbound Integrations to Salesforce

Sample Solutions for Inbound Integrations from Salesforce Using Pro-Code Tools

Scenario: A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

Custom Apex REST and SOAP Web Services You can create a web service using Apex code that could perform CRUD (create, read, update, delete) operations on the Contact object. This service would be invoked via SOAP or REST from the external system (the ERP).

MuleSoft Anypoint The intent of MuleSoft Anypoint is to provide enterprise grade API management. MuleSoft Anypoint offers a large set of prebuilt connectors that you can use to integrate with many ERP systems including SAP, Oracle EBS, Oracle ERP, and NetSuite. You can create a flow to listen for events in these ERP systems (in this case when a new contact is created). When the flow is kicked off it uses the Salesforce connector to create a new contact record (or update one if the contact already exists). Additionally, it is possible to integrate with other systems, if the replication transaction involves syndicating the contact into other systems. If needed, you can use the mapping and transformation language (DataWeave) to perform complex logic and calculations as information flows across multiple disparate systems. Authentication against these systems can be done through many different authentication mechanisms such as Basic Authentication and OAuth, among others. There are no restrictions on volume of transactions as long as the flow has been properly sized for its peak utilization (measured in vCores).

Native Salesforce APIs As (or immediately after) the update transaction in the ERP system completes, you can perform an upsert operation on the Contact object via the SOAP API or perform a PATCH against the Contact sObjects REST API in the Salesforce organization.

Salesforce to Salesforce Integrations

The Salesforce to Salesforce product has reached its end of life. Salesforce to Salesforce made it easy for partners working together to sell to and support joint customers, but Salesforce will be investing in bringing more innovation to other tools. Moving forward, the following approaches are recommended for sharing data between Salesforce organizations.

Tools for Data Integration Across Salesforce Organizations

Platform events are not optimal for integrating data from one Salesforce organization to another, because they can’t “listen” between organizations for the same event. Custom Apex is also not a recommended approach for this type of integration.

Use Cases for Integrating Data Across Different Salesforce Organizations

Data Aggregation (aka Hub and Spoke) Scenario: A large enterprise operates across multiple business units (BUs). Each BU has its own Salesforce organization. A single customer deals with multiple business units of the enterprise and thus has account and opportunity data in multiple organizations. The enterprise needs to access an aggregated view of all the Account and Opportunity data across all BUs in a single org.

Note: All scenarios below design for the least amount of data replication, in accordance with Takeaway #1.

Heroku Connect For each BU’s individual organization, you can use Heroku Connect to sync changes from Salesforce into a single Heroku Postgres database. In this scenario, bi-directional syncing would not be enabled, only syncing from Salesforce to Postgres. Then, in Heroku Connect, you can enable the OData provider and select the tables you want to expose as external objects in the Salesforce org where you want an aggregated view. From within Salesforce, you define an external data source pointing to the OData provider in Heroku.

MuleSoft Anypoint MuleSoft Anypoint provides enterprise-grade API management. A MuleSoft Anypoint API can be configured so that it reads information from multiple related Salesforce organizations using the Salesforce connector with multiple connections to the organizations. The MuleSoft flow can query the different Salesforce organization and return a specific structure that is enhanced or enriched with other third-party information if needed. When the API is invoked, it will make all the proper Salesforce organization callouts (in this example querying Account and Opportunity information) so that the data can be processed by the consumer (likely a UI). Authentication against these systems can be done through a variety of authentication mechanisms including basic authentication and OAuth. There are no restrictions on the volume of transactions, so long as the flow has been properly sized for its peak utilization (measured in vCores or Cores).

MuleSoft Composer MuleSoft Composer is intended to allow practitioners without developer skills to build integrations more easily. Composer Flows can also be invoked via an API call or via Flow with an Invocable Action.

Native Salesforce APIs Query operations can be issued to each of the organizations of interest, notably via the Salesforce Bulk API 2.0, which is well-suited to efficiently extract thousands of records. The can retrieve the query results from each organization individually and aggregate them with a custom application or middleware per customer requirements.

Salesforce Connect with Cross-Org Adapter The Salesforce Connect Cross-Org adapter is not a strong fit in this scenario, since Accounts or Opportunities from remote orgs will all appear in the central org as different objects. For example, there is no way to add up a grand total for the Amounts of all the Opportunities across all the orgs.

Selective Updates Cross-Org Scenario: A salesperson, using Salesforce organization A, needs to view and update case data from Salesforce organization B and add case comments to the parent case on Salesforce organization B while working in organization A. Data should not be replicated to organization A.

Heroku Connect You can use the same approach described in the Data Aggregation Scenario above. In this case, however, you enable CRUD on the external object via the OData connector and write the changes back to Heroku Postgres.

MuleSoft Anypoint MuleSoft Anypoint provides enterprise-grade API management. You can use the same approach described in the Data Aggregation Scenario above.

MuleSoft Composer MuleSoft Composer is intended to allow practitioners without developer skills to build integrations more easily. Composer Flows can also be invoked via an API call or via Flow with an Invocable Action.

Native Salesforce APIs Use Named Credentials and invoke the native Salesforce APIs to read and update data in the related Salesforce organization. A component would need to be designed to display the data.

Salesforce Connect with Cross-Org Adapter The ability to view data in an external object (as well as edit the data if you have CRUD enabled on the external object) is supported through the Salesforce cross-org adapter. Relationships are also supported between external objects so you can link to the parent case in the external object. However, creating relationships is a manual process today in which you convert an existing datatype to a relationship datatype. Additionally, optimizations made within Service Cloud to work with Cases more effectively do not cascade through to the remote org. Salesforce strongly recommends testing the Cross-Org Adapter and evaluating the tradeoffs in working with External Objects vs Standard Objects for your use case.

Data Synchronization Cross-Org: When an account for a customer is updated in one of the organization’s business unit Salesforce organizations, the other Salesforce organization Account objects need to be updated to keep consistent account information.

Heroku Connect You can use the same approach described in the Data Aggregation Scenario above. In this case, however, you enable bidirectional syncing, and you no longer need to enable Salesforce Connect as the bi-directional syncing will keep all the organizations up-to-date when changes are made to the Postgres table.

MuleSoft Anypoint MuleSoft Anypoint provides enterprise-grade API management. You can configure a Mule application with Flow Designer in MuleSoft Anypoint to listen for standard and custom object events to kick off an autolaunched flow in Salesforce. When the Mule application is triggered, it can invoke the Anypoint Connector for Salesforce to communicate with any number of Salesforce organizations. In this use case, when an Account record is updated in one Salesforce organization, the Mule app can update Account records in the related Salesforce organizations. Each related Salesforce organization would have a unique update step built into the overall application flow in MuleSoft. Authentication against these systems can be done through various authentication mechanisms, including basic authentication and OAuth. There are no restrictions on the volume of transactions as long as the flow has been properly sized for its peak utilization (measured in vCores or Cores).

MuleSoft Composer MuleSoft Composer enables practitioners without developer skills to easily build integrations. A flow configured with MuleSoft Composer can listen for standard and custom object events to kick off an autolaunched flow in Salesforce. When the MuleSoft Composer flow is triggered, it can invoke the Salesforce Connector to communicate with other Salesforce organizations (in this case related Salesforce organizations). In this use case, when an Account record is updated in one Salesforce organization, it can update the Account records in other related Salesforce organizations. Each related Salesforce organization would need a distinct flow step configured to handle the appropriate updates to Account records. Authentication against these systems is typically done via OAuth. There are no limits on the number of times a MuleSoft Composer flow can be invoked or the number of flows within an organization. Data insertion or update within a flow is measured as a task. Based on the license type, an organization can perform a certain number of tasks each month, and additional tasks can be purchased as needed.

Native Salesforce APIs The Replication API (getUpdated, getDeleted operations) could be used to sync data across orgs, but this approach is not recommended.

Salesforce Connect with Cross-Org Adapter You can use record-triggered flows and external objects to keep some data in sync between Salesforce organizations. For example, updating an account record in Organization A triggers a flow that then updates the matching record on the Account external object, which writes those updates to the account record in Organization B. This requires the proper use of flow semantics to avoid mixed DML transactions. Also, bear in mind that Validation Rules and Flows in Organization B will be triggered in the same way that they would if the change were made by our REST/SOAP APIs.

Closing Remarks

Keep this guide in mind and refer to it when you’re planning a new data integration involving Salesforce. It’s always a good idea to understand the full scope of options available to you, and how they may fit with your specific use case. Stay tuned for additional decision guides focused on event-driven integration, process integration, and more.

Tell us what you think

Help us make sure we're publishing what is most relevant to you: take our survey to provide feedback on this content and tell us what you’d like to see next.