In todays connected systems no application is an island. When implementing a CRM system like Salesforce, it will need to exchange data with other systems in the organization like ERP, People Systems etc. These other systems can be in the cloud and/or on-premises. As Salesforce is SaaS, and is cloud based, most of the integrations are done through Web API calls. Basically, to integrate with Salesforce there is three main Scenarios:

• Remote Process Invocation: – that is when the business process is a distributed across multiple applications including Salesforce and business process progress has to be communicated across these applications
• Batch Data Synchronization: – This is the most common scenario where you need to keep data between different systems periodically synchronized. It is also used for the initial data migration
• Data Virtualization: – utilizing Salesforce Connect, external data is virtually available in Salesforce as External Objects.

There is a fourth scenario that Salesforce Integration Patterns and Practices documentation describes which is based on Salesforce UI subscribing to Salesforce events to update the UI. I do not consider this to be an integration pattern as in my opinion it is an internal implementation pattern for a Salesforce custom implementation. Below is a high-level description of these integration patterns. In a real-world Salesforce implementation, you would typically implement several of these patterns for different integration scenarios.

Remote Process Invocation (Web API REST/ SOAP Call)

1. Request-Reply: Synchronous Call

In this scenario when an event occurs in Salesforce (such as a user entering certain information) Salesforce makes a Web API call to another system to inform it of the event with a data payload, Salesforce would wait for the remote system to complete the processing. This pattern is suitable for real time integrations where the data payload is small, and the continuation of the business process depends on the remote system completing processing. Things to consider are:

• How Salesforce authenticates into the Remote system,
• securing the Web API call,
• time for the remote system to finish processing and return the results,
• Salesforce governor limits, Number of Web API Calls to remote system.

1. Fire and Forget: Asynchronous Call

In this scenario when an event occurs in Salesforce (such as a user entering certain information) Salesforce makes a Web API call to another system to inform it of the event with a data payload, the remote system returns confirmation of receipt of the event. Salesforce would not wait for the remote system to finish processing. When the remote system finishes processing it calls back Salesforce to inform it of completion with the data that Salesforce needs. This pattern is suitable for real time integrations where the data payload is small, but the continuation of the process does not depend on the remote system completing the processing. Things to consider here are:

• How Salesforce authenticates into the Remote system,
• securing the Web API call,
• time for the remote system to finish processing and return the results,
• Salesforce governor limits,
  • Number of Web API Calls to remote system
  • Number of remote system Web AP Call-backs to Salesforce
    • Is it one call-back for each request?
    • Or the remote system calls back onetime for several requests.

1. Remote Call-In

The remote system connects and authenticate with Salesforce to notify Salesforce about external events, create records, and update existing records. There are to variation to this scenario:

1. The remote system calls into Salesforce to query, insert, update, upsert or delete data. You implement this pattern using either REST API for notifications from external events or SOAP API to query a Salesforce object. The sequence of events is the same when using REST API. the solutions related to this pattern allow for:
   1. The remote system to call the Salesforce APIs to query the database and execute single-object operations (create, update, delete, and so on).
   2. The remote system to call the Salesforce REST API composite resources to perform a series of object operations.
   3. Remote system to call custom-built Salesforce APIs (services) that can support multi-object transactional operations and custom pre/post processing logic.

1. In an event-driven architecture, the remote system calls into Salesforce using SOAP API, REST API, or Bulk API to publish an event to the Salesforce event bus. Event subscribers can be on the Salesforce Platform such as Process Builder Processes, Flows, or Lightning Components, Apex triggers. Event subscribers can also be external to the Salesforce Platform such as CometD subscribers.

Things to consider here are:

• How Remote System authenticates with Salesforce
• Securing the Web API call,
• Salesforce governor limits, Number of remote system Web AP Calls to Salesforce
  • Is it one call-back for each request?

Batch Data Synchronization

The scenario for this pattern is the initial data migration to Salesforce and the nightly/weekly/monthly updates. Here, the immediate propagation of data between systems is not important such as moving data to reporting systems or data warehouse et. The focus is on extracting data from source system, transforming it and loading it to the target system. An ETL middleware would be of great help in this scenario. Things to consider here are:

• Data volume.
• Securing the communication pipelines between Salesforce, ETL too and remote system.
• Securing data while in transmission between the systems.

Data Virtualization

This pattern is about how to view, search, and modify data that’s stored outside of Salesforce, without moving the data from the external system into Salesforce. There are various options to consider when applying solutions based on this pattern:

• Would a declarative/point-and-click outbound integration or UI mashup in Salesforce be satisfactory
• Is there a large amount of data that you don’t want to copy into your Salesforce org?
• Do you need to access small amounts of remote system data at any one time?
• Do you need real-time access to the latest data?
• Do you store your data in the cloud or in a back-office system, but want to display or process that data in your Salesforce org?
• Do you have data residency concerns for storing certain types of data in Salesforce?

You can Use Salesforce Connect to access data from external sources, along with your Salesforce data. Pull data from legacy systems such as SAP, Microsoft, and Oracle in real time without making a copy of the data in Salesforce. Salesforce Connect maps data tables in external systems to external objects in your org.. Accessing an external object fetches the data from the external system in real time. Salesforce Connect lets you:

• Query data in an external system.
• Create, update, and delete data in an external system.
• Access external objects via list views, detail pages, record feeds, custom tabs, and page layouts.
• Define relationships between external objects and standard or custom objects to integrate data from different sources.
• Enable Chatter feeds on external object pages for collaboration.
• Run reports (limited) on external data.
• View the data on the Salesforce mobile app.

To access data stored on an external system using Salesforce Connect, you can use one of the following adapters:

• OData 2.0 adapter or OData 4.0 adapter — connects to data exposed by any OData 2.0 or 4.0 producer.
• Cross-org adapter — connects to data that’s stored in another Salesforce org. The cross-org adapter uses the standard Lightning Platform REST API. Unlike OData, the cross-org adapter directly connects to another org without needing an intermediary web service.
• Custom adapter created via Apex — if the OData and cross-org adapters aren’t suitable for your needs, develop your own adapter with the Apex Connector Framework.

Things to consider here are:

• External objects behave like custom objects, but some features aren’t available for external objects.
• External objects can impact report performance.
• Securing the connection to the remote system.
• Cross-Site Request Forgery (CSRF) on OData external data sources.

UI Update Based on Data Changes

While Salesforce Integration patterns and practices describes this as an integration pattern, I think of it as Salesforce internal development techniques. As you are using Lighting components to refresh the UI with updated data in the Salesforce due to record updates or events. I just put it here for completion.