Salesforce Integration Patterns: How to Choose the Right One (2026 Guide)

What an integration pattern is, and why it comes before the tool

An integration pattern is a proven answer to a recurring question: how should two systems exchange this kind of data? It fixes three things before anyone writes code: who starts the exchange, whether the caller waits, and where the data lives afterwards.

Teams that skip this step usually pick a tool first and bend every flow to fit it. The result is the familiar mess: a nightly batch for data users need in seconds, or real-time callouts for a price list that changes once a quarter and eats API limits.

Salesforce documents its patterns in the Integration Patterns and Practices guide on its architects site. As of October 2026 it lists six patterns in three groups:

• Process integration: Salesforce triggers work in another system, or another system triggers work in Salesforce.
• Data integration: records are kept in step between systems, or Salesforce reacts to data changes.
• Virtual integration: Salesforce shows data that stays in the other system.

The rule that follows from it: choose a pattern per data flow, not per project. A typical org has a request-and-reply credit check, event-driven order handoff to the ERP and a nightly product sync, all at once. For the end-to-end picture of options and tools, start with our Salesforce integration guide.

The six patterns at a glance

Salesforce’s guide grades most of the technologies for each pattern as best, good or suboptimal. The “best-fit” column above follows those grades; older options still work but are not where a new design should start.

Remote process invocation: request and reply

What happens. Salesforce calls a remote system, waits for the response, and uses it right away, usually to update a record or show the user a result.

• Use it when a person or the next process step cannot continue without the answer, and the answer comes back fast. Small payloads only, never batches.
• Salesforce features. External Services for REST APIs with an OpenAPI 2.0 or 3.0 definition, called declaratively from Flow. Flow HTTP callout when there is no full spec. Apex HTTP or SOAP callouts through Named Credentials when you need code, and Continuations for long-running calls from the UI.
• Timing. Synchronous. Salesforce’s guide notes a configurable timeout of up to 120 seconds for Apex callouts, but a user will not wait that long. Set a short timeout and design for the slow case.
• Error handling. The caller handles errors: commit changes only after a success response, and show the user a clear message when the call fails. Send a unique message ID and use upserts so a retry doesn’t create a second record on the other side.
• Example. A rep clicks “Check credit” on an opportunity. A Flow calls the finance system’s credit API through External Services, writes the credit limit and status back to the account, and only then lets the rep move the deal to the contract stage.

Remote process invocation: fire and forget

What happens. Salesforce hands a message to another system, gets an acknowledgment that it arrived, and continues. The other system does the work in its own time.

• Use it when something happens in Salesforce that another system must act on, but nobody needs to wait for the result. This covers most “when X happens in Salesforce, do Y elsewhere” requests.
• Salesforce features. Salesforce’s guide rates Platform Events published from Flow, the Pub/Sub API, Change Data Capture and Event Relay (for Amazon EventBridge) as the best fit. Platform Events published from Apex and OmniStudio Integration Procedures are a good fit. Outbound messaging, async Apex callouts from triggers and custom components with async callouts are rated suboptimal.
• Timing. Asynchronous, usually seconds. High-volume platform events are kept for 72 hours, so a subscriber that was down can replay what it missed.
• Error handling. Salesforce publishes a platform event to the bus once and does not retry on its side, and events aren’t rolled back with the database transaction. So the subscriber owns queuing, retries and duplicate detection (a replayed event carries the same replay ID). Use “Publish After Commit” when subscribers depend on the record being saved, and add fault paths to the Flow that publishes.
• Example. An opportunity is set to Closed Won. A record-triggered Flow publishes an “Order Requested” platform event with the account, products and amounts. Middleware subscribes through the Pub/Sub API, creates the sales order in the ERP and calls back into Salesforce with the order number.

Outbound messaging deserves a note. It sends SOAP messages and retries until the receiver acknowledges them, which is why older integrations still use it. Salesforce’s guide calls it a legacy way of integrating and steers new solutions toward Flow with events and the Pub/Sub API.

Batch data synchronization

What happens. Large sets of records are extracted, transformed and loaded on a schedule, in either direction. One system is the master for each object.

• Use it when volumes are large, the data changes rarely or in bulk, and a delay of hours is acceptable. Salesforce’s guide says plainly that timeliness isn’t important for this pattern.
• Salesforce features. A third-party ETL (extract, transform, load) tool or integration platform (the guide names Informatica and MuleSoft) using Bulk API 2.0 for large volumes and REST for smaller ones, ideally reading only changed records. Data 360 (formerly Data Cloud) options appear in the guide for some scenarios. Data Import Wizard and Data Loader are fine for migrations and one-off fixes, but Salesforce says neither is a recommended base for an integration strategy.
• Timing. Asynchronous. Schedule loads outside business hours to avoid record locks and contention with users.
• Error handling. Keep a control table with the last successful run so a job can restart where it stopped. Bulk API returns per-record results; retry the failed records from them rather than re-running the whole job. Sort child records by parent ID to avoid lock errors.
• Example. Every night the ERP exports products, price books and stock levels. An integration job loads changed records into Salesforce with Bulk API 2.0, matched on the ERP product code stored in an external ID field.

Batch is the pattern most teams undervalue. If the business can live with overnight data, it is the cheapest to run and the easiest to debug. Our Salesforce data integration guide goes deeper into ETL tools, Data 360 and data quality.

Remote call-in

What happens. Another system connects to Salesforce to create, read, update or delete records, or to publish an event into Salesforce.

• Use it when the other system owns the moment: a website form submits a lead, a customer portal updates a contact, the ERP writes back an invoice status.
• Salesforce features. The guide rates the REST API, Composite API, Composite Graph API, GraphQL (for multi-object reads), Bulk API 2.0, and publishing Platform Events through the Pub/Sub API as the best fit. SOAP API and custom Apex web services are rated suboptimal for new work.
• Timing. Each call is request and reply from the caller’s side, so it is synchronous for single records and asynchronous for bulk jobs and events.
• Error handling. The calling system (or its middleware) owns timeouts, retries and idempotency. Upsert on an external ID instead of insert, so a retried call updates instead of duplicating. With the Composite API, a 200 response can still hide a failed subrequest, so check every result in the body.
• Example. Salesforce’s own guide uses printers that report supply levels: the on-premises system publishes platform events about ink cartridges into Salesforce, and automation in Salesforce acts on them, for example to start a replenishment.

Limits to plan for, from the same guide: the Composite API takes up to 25 subrequests per call, synchronous create, update and delete calls handle up to 200 records each, and an event message can be up to 1 MB. Daily API request allocations depend on your edition and licenses, so check yours in Setup before go-live.

Authentication, connected apps and API choice are covered in our Salesforce API integration guide.

UI update based on data changes

What happens. When data changes, the Salesforce screen updates without the user refreshing the page.

• Use it when users act on fast-changing status: a service agent waiting for a payment confirmation, a dispatcher watching job updates, a manager watching cases close.
• Salesforce features. In Salesforce’s design, a Flow or Apex trigger publishes a platform event, and a custom Lightning component on the page receives it through the Pub/Sub API. Change Data Capture events can play the same role for plain record changes.
• Timing. Near real time, with the usual three-day replay window on the event bus.
• Error handling. Salesforce’s guide warns that notifications are not guaranteed to arrive or to arrive in order, and changes made through the Bulk API don’t generate them. Treat the live update as a convenience: the record itself must stay correct, and a page reload must always show the truth.
• Example. The guide’s telecom case: when a rep closes a case successfully, a trigger publishes an event and a custom console component shows the manager an alert.

Data virtualization

What happens. Salesforce reads data from another system in real time and shows it on records and in lists, without storing a copy.

• Use it when users need to see external data (order history, invoices, archives) but you don’t want to pay for storage, keep a copy in sync, or reconcile two versions.
• Salesforce features. Salesforce Connect with external objects. According to the guide, adapters cover OData (Open Data Protocol) 2.0, 4.0 and 4.01, Amazon Athena, DynamoDB and Snowflake, GraphQL through AWS AppSync, another Salesforce org (cross-org), and custom Apex adapters for any HTTP API. For read-only analytics, the guide also points to Data 360 zero-copy options; when users must edit the data, Salesforce Connect is the choice.
• Timing. Synchronous, every time someone opens the data. The timeout is configurable up to 120 seconds, and server-driven paging returns at most 2,000 rows per page.
• Error handling. If the external system is down, the related list is empty or shows an error. Plan for that in the page layout and tell users what it means. External objects also don’t support everything a normal object does, so test reports, automation and search before you commit.
• Example. From the guide: a manufacturer exposes ERP orders through an OData endpoint, and agents see them on the account in Salesforce instead of running reports in the ERP.

Event-driven architecture: Platform Events, CDC and the Pub/Sub API

Events are not a seventh pattern. Platform Events, Change Data Capture (CDC) and the Pub/Sub API are the technology under fire and forget, UI updates and asynchronous call-in. Salesforce also publishes a separate decision guide on event-driven architecture, and its core advice is simple: use events for processes that don’t need a synchronous response, and prefer batch when the source data rarely changes.

According to Salesforce’s event-driven decision guide, Platform Events, CDC and the Pub/Sub API keep events for three days for replay, with a 1 MB payload limit. Publishing and delivery allocations depend on your edition and add-ons, so check them in your org’s limits before a high-volume design goes live.

Three rules from the same guide save most event designs:

• Don’t loop. Never publish an event from a trigger on the same event, and document which system publishes what, so two systems don’t bounce changes back and forth.
• Publish after commit for most cases, so subscribers never act on a record that was rolled back.
• Don’t use events for internal orchestration. Inside Salesforce, subflows or Flow Orchestrator are clearer.

How to choose a pattern: decision table

Find the row that describes the flow you are designing. The Avoid column is the choice teams most often make instead.

Which pattern fits your flow?

Pick one concrete flow, such as “send Closed Won deals to the ERP”, and answer for that flow only. Then run it again for the next one; mixed answers usually mean two flows hiding in one.

How to design a Salesforce integration, step by step

Steps 1 to 4 need only a whiteboard and the people who own the data. Tools enter at step 5, which is why this order holds whatever you end up buying or building.

1. List the data flowsOne line per flow: source, target, trigger, objects, volume per day and per peak hour, and who notices if it breaks. “Sync Salesforce with the ERP” is not a flow; “send Closed Won orders to the ERP” is.
2. Name the system of record for each objectAccounts in Salesforce, invoices in the ERP, tickets in the help desk. Two masters for the same field is how sync loops and overwrites start.
3. Set the timing honestlyAsk what happens if the data arrives in five minutes or tomorrow morning. Most flows need near real time at most; reserve synchronous calls for the few where a person waits.
4. Map each flow to a patternUse the decision table above. Expect two or three patterns in one project.
5. Choose the Salesforce feature and the transportFlow, Platform Events, CDC, Pub/Sub API, REST, Bulk API 2.0 or Salesforce Connect, plus the tool around it: native features alone, an iPaaS, MuleSoft or a small custom service.
6. Design keys and idempotencyAdd external ID fields for the other system’s keys, use upserts, and give every message a unique ID so retries and replays are harmless.
7. Design errors before the happy pathWho retries, how many times, where failures are logged, and who gets alerted. For events, how far back a subscriber can replay; for batches, how a job restarts.
8. Set up securityA dedicated integration user with the minimum permission sets, an external client app or connected app with OAuth, and Named Credentials for outbound calls. Salesforce includes a limited number of Salesforce Integration user licenses in supported editions.
9. Check limitsEstimate API calls, event publishing and delivery, and storage per day against your org’s allocations, with headroom for backfills and peaks.
10. Test in a sandbox with real volumesDuplicates, retries, an unavailable target, a bulk update of 50,000 records, and a subscriber that was down for a day. Then pilot one flow in production before switching on the rest.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Error handling and idempotency: the traps in every pattern

Where middleware fits, and when custom makes sense

Salesforce’s guide prefers middleware when an integration needs complex aggregation, orchestration or transformation, and when errors must be handled outside Salesforce. It names MuleSoft and Informatica; Workato, Boomi and other iPaaS (integration platform as a service) products fill the same role.

In practice middleware matters most for fire and forget (one event, several consumers) and batch sync (transformations, scheduling, restarts). Our Salesforce MuleSoft integration guide covers that route in detail.

A custom integration, usually a small service on the Salesforce APIs, makes sense when:

• You have one or two flows and an integration platform would cost more per year than building them.
• The logic is specific to your business: approvals, enrichment, filtering rules you need to audit.
• You need the Pub/Sub API, Bulk API 2.0 and your own systems’ APIs in one place, with retries and monitoring you control.

The pattern mix drives the price more than the tool does: a request-and-reply flow with error screens costs more than a nightly batch of the same data. The ranges are from our API integration cost guide, and batch-heavy or warehouse work is priced in the cost of data integration.

Design review checklist

Bring this to the design review before anyone writes code. Every unchecked box is a decision that will otherwise be made by accident during the build.

FAQ

Where Gilzor fits

Gilzor is a software development company with engineers in Poland and Cyprus, not a Salesforce reseller. We can turn a flow list like the one in step 1 into a pattern map, set up the events, APIs or batch jobs on Salesforce and your other systems, and support the integration after launch. Our Salesforce integration services page shows how that work is scoped.