Salesforce integration patterns are Salesforce's documented, proven designs for connecting Salesforce with other systems. The Salesforce Architects guide lists six: Remote Process Invocation (Request and Reply), Remote Process Invocation (Fire and Forget), Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes, and Data Virtualization. You pick one by asking which side starts the exchange, what is being integrated, and whether the caller needs an answer straight away.
This guide was first published in 2020 as "Top 5 salesforce integration patterns". It has been rewritten for 2026 with all six patterns, the tools Salesforce now rates best for each, and integration best practices.
What are the Salesforce integration patterns?
There are six, defined by who starts the exchange and whether the caller waits. The patterns come from Salesforce's Integration Patterns guide on the Architects site:
| Pattern | What happens | Direction | Timing |
|---|---|---|---|
| Remote Process Invocation: Request and Reply | Salesforce calls a remote process, waits for the response and updates records from it | Salesforce to other system | Synchronous |
| Remote Process Invocation: Fire and Forget | Salesforce hands off a request; the remote system acknowledges it and processes it later | Salesforce to other system | Asynchronous |
| Batch Data Synchronization | Scheduled batch loads create or refresh data in either system | Both | Asynchronous |
| Remote Call-In | An external system creates, reads, updates or deletes Salesforce data, or publishes events into Salesforce | Other system to Salesforce | Either |
| UI Update Based on Data Changes | The Salesforce screen updates as soon as underlying data changes | Salesforce | Asynchronous |
| Data Virtualization | Salesforce reads external data in real time without storing it | Salesforce reading external data | Synchronous |
How to choose an integration pattern
Choose a pattern by answering three questions: direction, type and timing. The guide classifies every integration on three axes:
- Direction: does Salesforce start the exchange, or does the other system call in?
- Type: process integration (a business process spans applications, with transactional concerns), data integration (keeping information in step), or virtual integration (showing external data without copying it).
- Timing: synchronous (the caller waits for the result) or asynchronous (the message is queued and the result comes later).
Its selection matrix then maps the answers to a pattern. When Salesforce starts the exchange: a synchronous process or data need is Request and Reply; an asynchronous process is Fire and Forget; asynchronous data is UI Update Based on Data Changes; and virtual is Data Virtualization. When the other system starts it: everything synchronous, and asynchronous processes, are Remote Call-In; asynchronous data is Batch Data Synchronization.
Real-world examples of each pattern
Each pattern in the Architects guide comes with a worked scenario. In short:
| Pattern | Example from Salesforce's guide |
|---|---|
| Request and Reply | During ordering, Salesforce calls a billing system to create a billing account and stores the account number it returns |
| Fire and Forget | When an opportunity is closed-won, Salesforce publishes an event that an ESB passes to the ERP to create the order |
| Batch Data Synchronization | Prospect assignments are imported nightly from a mainframe with an ETL tool and change data capture |
| Remote Call-In | An external billing system updates order status in Salesforce as orders change |
| UI Update Based on Data Changes | Service managers see an alert when a case closes: a trigger publishes a platform event and a custom UI subscribes to it |
| Data Virtualization | Agents see live ERP order data inside Salesforce through Salesforce Connect, without logging in to the ERP |
For common business systems, our guides to Outlook and LinkedIn integration show how these patterns appear in practice.
Which Salesforce integration tools fit each pattern?
As of November 2026, Salesforce rates REST, Bulk API 2.0, Pub/Sub API, platform events, External Services and Salesforce Connect as the best fits for most patterns. The same guide rates technologies for each pattern as Best, Good or Suboptimal. The ones rated Best:
| Pattern | Rated best | Rated suboptimal |
|---|---|---|
| Request and Reply | External Services (REST with an OpenAPI spec); Apex callouts using Named Credentials from Lightning components | Callouts from Apex triggers and batch Apex |
| Fire and Forget | Platform events published from Flow; Pub/Sub API; Change Data Capture; Event Relay for AWS | Outbound messaging (legacy); async callouts from triggers |
| Batch Data Synchronization | ETL tools using Bulk API or Bulk API 2.0; Data 360 data actions and activations; Composite Graph API | Using Remote Call-In or Request and Reply for batch loads |
| Remote Call-In | REST API; Composite API; Bulk API 2.0 for large volumes; GraphQL API for complex reads; Pub/Sub API and platform events | SOAP API; custom Apex web services and Apex REST |
| UI Update Based on Data Changes | Platform events streamed through Pub/Sub API to a Lightning component | (not rated) |
| Data Virtualization | Salesforce Connect; Data 360 with Zero Copy | Ad-hoc callouts from custom pages or buttons |
Two details change many designs. For Remote Call-In, the guide suggests Bulk API 2.0 for loads typically over 2,000 records. For UI updates, it notes that event delivery and ordering aren't guaranteed, that the event topic keeps a 72-hour replay window, and that changes made through the Bulk API don't generate notifications.
Data Import Wizard and Data Loader are fine for one-off loads, but the guide does not recommend them as the base of an ongoing integration.
Where middleware such as MuleSoft fits
Use middleware when an integration needs aggregation, transformation, orchestration or transactions across several systems. Salesforce's guide says to use middleware for aggregation, transformation, orchestration and transactional integrity across systems, because Salesforce APIs don't handle those in the platform. MuleSoft's Anypoint Platform is the option MuleSoft positions for use alongside Salesforce, with more than 1,500 prebuilt connectors; ETL and iPaaS tools such as Jitterbit or Zapier cover simpler cases. A rough rule:
- Point-to-point is enough when one system talks to Salesforce, the data maps simply, and volumes are modest.
- Middleware pays off when several systems share the same data, formats need transforming, a process spans systems and must roll back cleanly, or you want one place to monitor every integration.
Our MuleSoft integration page covers that route, and our comparisons of Workato vs MuleSoft and Workato vs Zapier help choose a platform.
Salesforce integration best practices
Secure every connection, design for retries, respect time limits and decide the system of record before you build. From the guide's security, error-handling and design advice, plus what we see go wrong in practice:
- Authenticate with OAuth and Named Credentials. Use OAuth for REST and Bulk API 2.0 and reuse tokens; use Named Credentials for Apex callouts instead of storing credentials in code or custom settings.
- Encrypt everything. HTTPS for every connection; TLS 1.2 or later for SOAP.
- Restrict API access with a dedicated integration user, minimal permissions and IP restrictions.
- Design for retries. The remote system or middleware must handle the same call twice without creating duplicates, because retries and timeouts happen. Use external IDs and upserts.
- Recover missed events. Subscribers should store replay IDs so they can fetch platform event messages they missed.
- Respect time limits. Salesforce Connect waits up to a configurable 120 seconds for an external response, and each SOQL query has a 120-second timeout. Keep synchronous calls short, and move slow work to asynchronous patterns.
- Mind the limits. Integrations share the org's API and governor limits; callouts from triggers are rated suboptimal for this reason.
- Decide the system of record for each object and field before building, so two systems don't overwrite each other.
- Log and monitor. Every integration needs an error log someone reads, and an alert when it stops.
Common mistakes
The most common integration mistakes are synchronous calls that should be queued, copying data that could be virtualised, and legacy techniques in new builds.
- Synchronous callouts for work that could be queued, which makes users wait and fail when the other system is slow.
- Copying large external tables into Salesforce when Salesforce Connect could show them on demand.
- Building new integrations on outbound messaging or custom SOAP services, which the guide treats as legacy or suboptimal. Our Salesforce API developer guide covers the current APIs.
- No sandbox copy of the external system, so integrations are first tested in production. See our sandbox guide.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce integration services team designs and builds integrations with ERP, finance, telephony and marketing systems; see our integrations page for common ones. Talk to us about yours.
Frequently asked questions
What are the Salesforce integration patterns?
Salesforce's Architects guide lists six: Remote Process Invocation (Request and Reply), Remote Process Invocation (Fire and Forget), Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes, and Data Virtualization.
How do you choose a Salesforce integration pattern?
Answer three questions: which system starts the exchange (Salesforce or the other system), whether you are integrating data, a process or a virtual view of data, and whether the caller needs an immediate answer (synchronous) or not (asynchronous). Salesforce's selection matrix maps each combination to a pattern.
What is the difference between Request and Reply and Fire and Forget?
In Request and Reply, Salesforce calls the remote system and waits for the response before continuing. In Fire and Forget, Salesforce sends the request, the remote system only acknowledges receipt, and the work is processed asynchronously; platform events are the usual tool.
Which API should an external system use to load data into Salesforce?
For small, real-time changes, the REST or Composite API. For large volumes, Bulk API 2.0: Salesforce's guide recommends it for loads typically over 2,000 records. For scheduled syncs, an ETL or middleware tool that uses the Bulk API.
Do I need MuleSoft to integrate Salesforce?
Not always. Point-to-point APIs, platform events and Salesforce Connect cover many needs. Middleware such as MuleSoft is worth it when you need transformation, orchestration across several systems, or transactional integrity, which Salesforce's guide says its APIs don't handle in-platform.