Salesforce integration patterns: how to choose the right one
Request-reply, fire-and-forget, batch sync, events or virtualization? A practical guide to picking a Salesforce integration pattern, with the trade-offs explained.
By Vitap, Founder & Salesforce Architect. Published 29 September 2026. 3 min read.
The short answer
Pick the pattern by asking two questions: does the user need the answer right now, and which system starts the conversation? Use request-reply for real-time answers, fire-and-forget or Platform Events when Salesforce only needs to notify, batch sync for large nightly volumes, and data virtualization when data should stay in the other system.
Most Salesforce integration problems we're asked to fix weren't caused by bad code. They were caused by the wrong pattern: a synchronous callout where nobody needed an instant answer, or a nightly batch where sales needed data within minutes.
Salesforce's own architects describe a small set of integration patterns. Choosing between them comes down to a few questions you can answer before anyone writes code.
Two questions that decide most integrations
Does a person need the answer right now? If a sales rep is waiting on a screen for a price, stock level or credit check, you need a synchronous pattern. If not, go asynchronous. It's more resilient and kinder to API limits.
Which system starts the conversation? If Salesforce initiates, you're making callouts from Salesforce. If the other system initiates, it calls Salesforce's APIs. The answer changes who owns authentication, retries and error handling.
The patterns, in plain language
| Pattern | Who starts | Timing | Good for |
|---|---|---|---|
| Request and reply | Salesforce | Real time | Pricing, availability, validation |
| Fire and forget | Salesforce | Near real time | Sending orders or updates onward |
| Batch data synchronization | Either | Scheduled | Large volumes, reporting data |
| Remote call-in | External system | Real time or near | ERP or website pushing data in |
| UI update on data change | Salesforce | Real time | Live dashboards and consoles |
| Data virtualization | Salesforce | On demand | Data that should stay where it is |
Request and reply
Salesforce calls an external API and waits for the response, usually from Apex behind a Lightning Web Component or a Flow action. Keep these calls fast and few. Set sensible timeouts, use Named Credentials for authentication and always design what the user sees when the other system is down.
Fire and forget
Salesforce sends a message and moves on. Publishing a Platform Event or using an outbound message lets the user continue while the other system processes the change. You need a way to know if delivery failed, so log every message and its outcome.
Batch data synchronization
When you're moving tens of thousands of records, a scheduled job using the Bulk API is the right tool. It's predictable and efficient, but data is only as fresh as the last run. Agree that freshness with the business up front.
Remote call-in
The external system calls Salesforce's REST, SOAP or Bulk APIs to create or update records. Give it a dedicated integration user with only the permissions it needs, and use upsert with external IDs so retries don't create duplicates.
UI update based on data changes
When a record changes, the screen should reflect it without a refresh. Change Data Capture or Platform Events combined with the Lightning empApi make consoles feel live.
Data virtualization
Sometimes data shouldn't be copied at all. Salesforce Connect exposes external data as external objects, so users see it in Salesforce while it stays in the source system. It's ideal for large, read-mostly datasets you don't want to store twice.
What makes any pattern reliable
The pattern is half the job. These habits make the difference in production:
- Decide the system of record per field. Write it down. Most sync bugs are two systems both believing they own the same data.
- Use external IDs and upserts. Retries then become safe.
- Log every request and failure. A custom object or external log, with enough detail to replay the message.
- Retry transient errors automatically and alert on the rest. A named person should hear about failures before customers do.
- Watch your limits. API allocations, callout limits and event delivery allocations all grow with your volumes.
Where to start
If you're planning a new integration, sketch the data flow on one page: systems, direction, timing and owner for each flow. That page will usually tell you the pattern. If you'd like a second opinion, our Salesforce integration team reviews designs like this every week.
Frequently asked questions
What is the most common Salesforce integration pattern?
Request and reply over REST is the most common, because users often need an immediate answer, such as a price or a stock level. It is also the easiest to overuse: if the user doesn't need the answer instantly, an asynchronous pattern is usually more reliable.
Should I use Platform Events or Change Data Capture?
Use Change Data Capture when external systems need to know that a Salesforce record changed. Use Platform Events when you want to publish a business event with a custom shape, such as 'order approved', independent of any single record.
Do I need middleware for Salesforce integrations?
Not for every project. Native callouts and events handle many one-to-one integrations well. Middleware earns its cost when you connect many systems, need heavy transformation or want a non-Salesforce team to own the integrations.