Enhance Salesforce Insights with 8 System Integration Options

Salesforce provides and accommodates options for integrating with other systems. Let’s review the options, including key considerations and limitations, when choosing how to move forward with Salesforce CRM integration.

As the world’s leading CRM platform, Salesforce is used by numerous organizations across the world. It offers various “Clouds” that manage key business processes like “Sales” and “Service” — core platforms for your business.  

However, in today’s complex enterprise that crosses multiple software applications, a data input or change in Salesforce requires updating another system, whether internal or external. The reverse is true as well — updates to data in other systems require data updates in Salesforce.  

By automating these updates, you don’t have to worry about making manual updates as your organization grows and these transactions can multiply themselves. Enter the world of integration, which enables one system to connect to another system and send, receive and/or update data.  

In this blog, we will cover the various Salesforce integration tools or methods that are available to send and receive data from Salesforce.  

Salesforce CRM Integration Methods 

Salesforce provides and accommodates various options for integrating with other systems. We will go over those options and talk about when you should use one over another, including some of the key considerations. We’ll also briefly touch on some of the limitations.  

The types of CRM integrations we will cover are: 

• Publish-Subscribe Messaging Based 
• Change Data Capture 
• Virtual Integration 
• Third-party Integration Tools 
• Data Loading 
• Salesforce Connect 
• Inbound into Salesforce  
• Outbound from Salesforce 

Data Loading 

In this type of integration, data is generally pushed into Salesforce. One example of data being pushed into Salesforce is the initial data load to standard or custom objects within Salesforce, especially when moving from older custom-built software systems. This usually includes extracting and transforming large amounts of data and preparing load sheets to push data into Salesforce.

Out–of–the–box Salesforce provides two free tools you can use to accomplish the data load: 

• Data Import Wizard: A more friendly, wizard-based tool is very simple and recommended for non-technical users. It allows importing data into custom objects and supports data load into some standard objects, including up to 50,000 records. It can also be used to extract data from Salesforce. While it is a good tool, it has limits that quickly become a bottleneck for any large complex data load requirements.  
• Data Loader: A downloadable tool, Data Loader can be used for large data loads into standard and custom objects. It also offers the user the option to select a batch size and run the batches in serial or parallel. Data Loader has many benefits, but is not easy from an end-user perspective and has limitations for large data migrations. However, Data Loader should still be the first choice for getting data into and out of Salesforce. Below is more detail about how the tool works:
  • Data Loader can be automated and invoked through shell scripts, which makes it an excellent option if the data load is something that occurs on a regular basis. For example, if you use the windows task scheduler and call the script that invokes Data Loader, it picks up input files from a source location and uploads the data into Salesforce. It is configurable to a certain degree, and settings can be passed while invoking the tool. It does have some limitations; data must be prepared correctly before it can be inserted into Salesforce. Users must manage duplicates, row locking issues, and slow data when loading large amounts of data with complex relationships. 
  • Data Loader can also be used to extract data from Salesforce. It does have some limitations; data must be prepared correctly before it can be inserted into Salesforce. Users must manage duplicates, row locking issues, and slow data when loading large amounts of data with complex relationships. 

Salesforce Connect 

Salesforce provides an out-of-box way of viewing external data called Salesforce Connect which uses special entities called external objects. Think of this as a view to an external data store, but it is a special view that you can also use to update the external data source.

The best part: It does not take up Salesforce data storage space. This is an important consideration since while Salesforce can handle very large amounts of data, the storage does not come cheap. Before moving data to Salesforce, it’s a best practice to make sure the move is required (into either Standard or custom objects). 

Salesforce Connect requires you to create an OData endpoint to get data from any external system. An OData endpoint exposes external data, such as data stored in your SQL Server as tables or view as JSON objects. This endpoint should be hosted publicly so that is accessible by Salesforce application servers, and if desired, you can also configure authentication to your endpoint (Salesforce allows you to pass these credentials per user or provide a generic account for all users). 

You can use a single OData endpoint to expose multiple tables as multiple external objects inside Salesforce. You can also configure other settings on the OData endpoint to make these external objects writable, sortable (and more) from within Salesforce. The user viewing the data will not know if the data is living outside Salesforce in an external system. External objects are searchable, and you can create reports and dashboards using them. Additionally, they can also be related to standard, custom or other external objects.  

External objects do have limitations and they should not be used as a replacement to standard or custom Salesforce objects. Salesforce Connect requires an additional license per organization and data source, which means you must buy two licenses to connect two source systems.

Salesforce Connect offers an excellent way to get and write data to external systems while providing users with a familiar Salesforce User Interface. Also, Salesforce Connect takes into account the fact that your organization’s data storage is bound to grow over time, making it a viable option that can provide you with significant savings in the long run.

Inbound into Salesforce 

For all standard and custom objects, Salesforce provides out-of-the-box REST and SOAP API Endpoints that can be used by external systems to perform CRUD operations on data residing inside Salesforce. To connect to these endpoints a connected app must be created inside Salesforce.

The calling system uses the credentials specified in this connected app and OAuth to perform various operations. Making this OAuth call typically requires a client key and secret code after which the client gets a refresh token that grants them access. The connected app can use different authentication mechanisms such as Password, JWT, etc. The information can be exchanged in various formats such as JSON, XML, etc. 

A developer can also write Custom APEX REST endpoints that allow custom logic to execute before the REST Actions can be performed on the objects. For example, before making an account inactive, we want to make sure that all the associated contacts are deactivated as well. Custom objects with customized exception messages can be sent back as well, allowing the calling system to handle various scenarios.  

These Endpoints provide a great mechanism for a near real-time integration, or requests can also be batched. As with other solutions, there are limitations to consider, including the total number of API calls and the size of the request.

The limitations can quickly become an issue when the system grows, and more communication needs to happen based on growing operations. It’s important to note this type of integration is synchronous, which means that if for any reason (like loss of connectivity or if the two systems cannot connect) there is a high probability of losing either the request or the response message. Therefore, you must perform extensive testing and exception handling, especially for long-running scenarios, before deploying these solutions in production.  

Outbound from Salesforce 

To retrieve data from Salesforce, external systems can use the REST Endpoints discussed above to make GET calls. Salesforce also provides “Outbound message,” which is a no-code solution that can be used when a standard or custom object is created or updated inside Salesforce.

Outbound messages offer admins or power users the capability to post standard or custom fields on the object to a URL. They are used as workflow actions in workflows within Salesforce. They can send the message in an XML format which is ideal for a SOAP endpoint. It is worth noting that currently there is no support to send the message in JSON format, however one workaround is creating a formula field and formatting the message in JSON and sending that field as part of the payload.  

Salesforce also provides HTTP Callouts which can be used within Salesforce Code to call an external REST or SOAP endpoint. An example would be to put the HTTP callout in an insert or an update trigger on an object to update an external system; for example, when an order is updated in Salesforce and it needs to update inventory in SAP.

Salesforce also provides APEX Batch jobs which can be scheduled at certain time intervals. The reason I mention them is they can be beneficial when processing multiple records as batches at the end of the day or week to then POST to an external endpoint using HTTP Callout.  

Publish-Subscribe Messaging-Based 

The Publish-Subscribe integration pattern allows a subscriber system to be notified when a publishing system publishes content. This integration mechanism is message-based because if the subscriber system does not pick up the message right away, it can be picked up later, making it asynchronous. This eliminates issues associated with an external system being unavailable or messages getting lost. Salesforce offers some interesting technologies in this paradigm.

Platform Events can be created inside the Salesforce User Interface from the setup. A Platform Event is a special object that has custom fields and can have events ‘raised’ against it. When we create a platform event, Salesforce provides us a unique endpoint for each event which can be used by an external system to subscribe to any events raised on the object.

External systems can subscribe to these events using a CometD client. There are various implementations available for .NET and Java frameworks. A client-server process can listen to any events that are raised from Salesforce when it subscribed to that endpoint.

The client receives data and all the fields that have been defined on the original platform event. Platform events can be granted permissions since these are “almost“ custom objects so that only certain users can raise them. They can be raised from within Salesforce using various mechanisms; for example, an after-insert trigger on a custom object that raises a platform event to inform the external clients when a new object is created. Internally you can capture the raised event using a trigger on the Platform Event object.

This means that internally in Salesforce or externally from another system, when a platform event is raised the trigger fires which can be used to perform a required action such as logging the event.   

Change Data Capture 

Change Data Capture (CDC) allows external systems to receive changes that happen inside Salesforce. When they are subscribed to the CDC channel, they will receive updates from within Salesforce in a JSON format (and Salesforce sends only the updated data).

This provides an excellent mechanism for an external system to receive updates without doing any polling. An additional benefit is the payload is small, which can make it ideal for large organizations with multiple connected systems. 

Virtual Integration 

A virtual integration is popular when organizations want their employees to use only a single software platform or do minimal software switching while working on various tasks. Salesforce offers IFrames to connect to external systems and can act as a “one-stop” system for external software systems that are browser-based.

For other types of systems, Visualforce pages and lightning components can pull information and enable users to perform all their tasks within Salesforce. Additionally, Salesforce also provides Canvas which is a set of components that enables users to make a canvas app that can integrate with a third-party application.  

Although Salesforce can act as a user interface to external applications, systems with complex sharing and security requirements are not ideal for bringing “into” Salesforce and must be managed separately. 

Third-Party Salesforce CRM Integration Tools 

There are various third-party Salesforce CRM integration tools that are available to connect external systems with Salesforce. One such tool is MuleSoft, which is owned by Salesforce and offers various connectors and accelerators that provide a jumpstart into your integration with various other external systems.

MuleSoft allows you to quickly create APIs that can get data from various systems and allows developers to create process orchestrations which can be very time-consuming and error-prone if done using custom code. MuleSoft is not free and has a license cost. 

Final Thoughts

There are lots of options available for communication to and from Salesforce. Complex Salesforce organizations should expect to use a combination of CRM integration tools and methods discussed above for an efficient and scalable integration solution.