9 Salesforce Integration Patterns for Syncing Apex, MuleSoft, and External Systems

Salesforce rarely runs alone. Customer records may start in CRM, orders may live in an ERP, payments may move through a gateway, and support activity may come from another platform. The hard part isn’t making 2 systems talk once. The hard part is choosing a repeatable way to move requests, events, and records without creating duplicate data, hidden dependencies, or failures that are hard to recover.

Salesforce integration patterns give architects a known way to match timing, data ownership, transaction size, and failure handling to the right feature or middleware path. Salesforce groups common needs into process, data, remote access, and virtual access patterns. The current Salesforce architecture guide to integration patterns makes the core point clear: start with the scenario rather than a favored tool, because the same endpoint can need a different design when timing or volume changes.

This guide focuses on 9 Salesforce integration patterns that cover the most common ways Apex, MuleSoft, APIs, events, and outside platforms exchange work. It explains when each pattern fits, how the data moves, where errors belong, and what usually goes wrong when teams choose a pattern for convenience instead of intent.

TL;DR

Use synchronous request and reply when Salesforce must wait for an outside answer during the current user action. Use asynchronous fire-and-forget when Salesforce can hand work off and continue. Put MuleSoft between systems when orchestration, protocol changes, shared APIs, or central policy belong outside the org. Use Platform Events when the message is a business event. Use Change Data Capture when consumers need record-change notifications. Let outside applications call Salesforce APIs when the remote side owns the process. Use Bulk API 2.0 for large record jobs. Use Salesforce Connect when users need live outside data without copying it. Use bidirectional synchronization only after each field and object has a clear system of record.

The best design uses the fewest moving parts that still meets timing, recovery, security, and ownership needs. Salesforce’s integration pattern learning guide separates business logic, data, and event needs because they fail in different ways. Use that split before choosing Apex callouts, middleware, event consumers, or Salesforce API integration endpoints.

What Salesforce Integration Patterns Actually Solve

Salesforce integration patterns are reusable answers to recurring architecture questions. Does Salesforce start the work, or does another system start it? Must the caller wait for the answer? Is the payload a single transaction, a stream of changes, or millions of records? Does Salesforce need its own copy of the data? Those questions matter more than whether the team prefers Apex, Flow, MuleSoft, REST, or an event bus.

The first design axis is direction. An outbound path starts inside Salesforce. An inbound path lets another service create, query, or change Salesforce data. Two-way designs still need clear ownership and conflict rules. A simple bidirectional diagram can hide those decisions.

The second axis is timing. Synchronous work waits for a result. Asynchronous work records the request or event for later processing and lets the caller continue. Salesforce’s request and reply pattern guidance places synchronous remote invocation in small real-time transactions because user-facing work has tighter limits. Network delay and remote outages are normal, so remote services should never be treated like local methods.

The third axis is data ownership. Replication means Salesforce stores a copy. Virtual access means the data stays in the outside platform and is fetched when needed. Event delivery means the message describes something that happened and lets subscribers decide what to do. Salesforce API integration can support all 3 ideas, but the API choice alone doesn’t define the architecture.

How To Choose The Right Pattern Before You Build

Start with the business event and the system of record, then choose the transport. A useful design statement names who starts the work, who owns the result, how fast it must finish, and what happens after failure. Use the decision points below before picking a tool.

Use measured volume instead of vague growth assumptions. Small JSON requests fit normal REST and Apex callouts. Large extracts belong in job-based APIs or middleware with restart controls.

Authentication belongs in the pattern decision because it affects ownership and deployment. For outbound callouts, current Salesforce guidance favors the newer Named Credentials and External Credentials model instead of putting endpoints or tokens in Apex. The Named Credentials developer guide notes that legacy named credentials are deprecated and recommends the newer model, which separates the endpoint from the external authentication setup. That makes Apex callouts easier to move between environments without hard-coded secrets.

Finally, define recovery before implementation. Decide which failures can be retried, how duplicate requests are detected, where failed payloads are stored, and who can replay them. A Salesforce integration that works only on the happy path isn’t ready for production. Remote timeouts, partial failures, expired credentials, and out-of-order messages should be treated as expected states rather than unusual defects.

Pattern: Synchronous Request And Reply With Apex

Use synchronous request and reply when Salesforce starts a remote action and needs the answer before the current process can finish. Common examples include checking inventory before quoting, validating an address during case intake, calculating tax, or creating a payment authorization that must return a result to the user. The key condition is that the response changes what Salesforce does next in the same interaction.

Apex callouts fit when the remote service exposes HTTP or SOAP and the logic needs code. The tradeoff is direct dependence on network response time, so keep this path for work that truly needs an immediate answer.

How The Request Moves

1.      A Lightning Web Component, Flow action, or Apex service starts the request.

2.      Apex calls the endpoint through a Named Credential and sends the required payload.

3.      The method parses the response and updates Salesforce or returns a value to the UI.

4.      Transport errors follow a separate recovery path from valid business rejections.

Treat latency as part of the requirement. If later completion is acceptable, move the work to an asynchronous pattern instead of keeping the user behind a remote dependency.

Error handling should separate business rejection from transport failure. A valid “credit limit exceeded” response is not the same as a timeout or DNS error. Save enough context to support diagnosis without storing secrets or sensitive response bodies that have no business need. Use correlation IDs when the external service supports them so a Salesforce transaction can be matched to remote logs.

A simple fit check works well for Apex callouts: Salesforce owns the trigger, the payload is small, the remote endpoint is dependable, and the answer is needed now. If one of those conditions changes, the design may fit another Salesforce integration pattern better.

Pattern: Asynchronous Fire-And-Forget From Salesforce

Use fire-and-forget when Salesforce needs to start work but doesn’t need the final result in the same transaction. Examples include sending a fulfillment request after an order is accepted, asking a document service to generate a file, or notifying a downstream system that a case reached a new state. The user can continue while the remote process finishes independently.

In Apex integration work, Queueable Apex is often a better boundary than making remote work inside the initiating transaction. The transaction captures the business event, enqueues the job, and ends. The queueable job performs the remote request and records the result. This keeps user-facing work from depending on the outside service and gives the team a clearer place for retry logic.

Fire-and-forget doesn’t mean “send and forget about operations.” You still need delivery evidence and recovery rules. Store a stable business key and an idempotency key if the receiver supports one. Record attempts, status, and the last failure reason in a way operators can search. Avoid blind automatic retries for permanent errors such as invalid data because they create noise and wasted API traffic.

Platform events can support this pattern when the sender shouldn’t know every receiver. Salesforce’s event design discussion for Change Data Capture and Platform Events separates record-change notices from custom business events. If one action may feed several consumers, an event can be cleaner than several direct calls.

Choose this pattern when Salesforce starts the work, immediate completion isn’t required, and you can define an operational record of what was sent. It is especially useful when the outside system has variable response time or planned maintenance windows.

Pattern: MuleSoft As The Shared Integration Layer

Use MuleSoft integration when the problem is wider than a single Salesforce-to-endpoint call. Middleware earns its place when several systems need the same business service, when messages need major reshaping, when protocols differ, or when routing and policy should be managed outside Salesforce. It also helps when teams want a stable API contract while back-end systems change behind it.

Salesforce should call a contract that represents the business capability it needs. MuleSoft can then reach an ERP, database, legacy SOAP service, file drop, or another API without exposing those details to Apex. The MuleSoft Salesforce Connector documentation lists batch synchronization, remote call-in, fire-and-forget, request and reply, and UI-update scenarios. MuleSoft integration can therefore implement several Salesforce integration patterns rather than stand as one universal pattern.

Keep business ownership clear. Salesforce validation rules should protect Salesforce records. Cross-system orchestration that spans several applications often belongs in MuleSoft because it can manage the whole flow from one place. Data mapping that is shared by several consumers also fits better in a shared layer than duplicated Apex classes. The wrong split creates the opposite problem, with simple Salesforce logic moved into middleware for no clear reason.

Security design should also be explicit. Decide whether MuleSoft acts as one integration identity or passes user context where required. Limit the Salesforce permissions of integration users to the objects and fields the flow needs. Store external credentials in the platform designed to own them instead of moving secrets through payloads.

Agree on logging boundaries before deployment. Salesforce, MuleSoft, and the back-end system should share a correlation key while each stores the detail it needs. Salesforce’s MuleSoft integration implementation guidance stresses early agreement on responsibilities, mappings, security, environments, and where business logic lives. Those choices keep troubleshooting from turning into a search across unrelated logs.

Pattern: Publish And Subscribe With Platform Events

Use Platform Events when Salesforce needs to publish a business event that one or more subscribers can react to without the publisher waiting for each one. Good event names describe something that happened, such as OrderAccepted, ClaimSubmitted, or ShipmentDelayed. Subscribers can be Apex, Flow, or external clients, and they can evolve without changing the publishing code as long as the event contract remains compatible.

This pattern works well for loose coupling. A sales process can publish an OrderAccepted event without knowing whether finance, fulfillment, analytics, or a notification service consumes it. Salesforce’s Platform Events publishing guide documents publishing from Apex and Flow as well as from outside applications through Salesforce APIs. That range makes event-based Salesforce integration useful when the same business signal needs both on-platform and external consumers.

For new external event clients, pay attention to the current API direction. Salesforce’s architecture material marks CometD-based Streaming API as a legacy path for new designs, while the Pub/Sub API guide describes one gRPC and HTTP/2 interface for publishing and subscribing to platform events and Change Data Capture events. An external system integration that is starting now should evaluate Pub/Sub API before copying an older Streaming API example.

Event design needs the same discipline as API design. Keep the event focused on the business fact and include identifiers that let subscribers fetch more detail if needed. Don’t publish entire Salesforce records by habit. Large event payloads increase coupling and make schema changes harder. Also decide whether consumers need committed transaction data before they act, because publish timing affects what a subscriber may observe.

The pattern is strongest when Salesforce doesn’t need a reply, several consumers may care about the same fact, and each subscriber can manage its own retry and processing state.

Pattern: Change Data Capture For Record Synchronization

Use Salesforce Change Data Capture when consumers need to know that Salesforce records changed. Instead of writing trigger code for each create, update, delete, or undelete, select supported objects and let Salesforce publish change events. Consumers can use record identifiers and change metadata to update their copy or start downstream work.

CDC is different from a custom Platform Event. A custom event models a business fact that you define. CDC describes changes to Salesforce records. The distinction matters because using record changes as a substitute for business events can leak Salesforce object structure into every consumer. Use CDC for Salesforce data integration when the external system really needs record-level synchronization, not when it only needs to know that a business process reached a milestone.

For record synchronization, Salesforce documents the supported CDC behavior in its Change Data Capture guidance, including create, update, delete, and undelete notifications. Salesforce Change Data Capture also supports replay within the documented retention window. Consumers still need to persist their position and handle duplicates safely.

A good CDC consumer applies idempotent updates. If the same change is seen twice, processing it twice should not corrupt the target. The consumer should also account for transaction boundaries and ordering rules rather than assuming every event arrives as an isolated row update. When the target has its own system-of-record rules, map only the fields Salesforce is allowed to own.

CDC often works well beside MuleSoft integration. MuleSoft can consume the stream, apply mapping or routing, and then update several target systems. That keeps Salesforce free from direct knowledge of every downstream endpoint while still using Salesforce-native change events.

Pattern: Remote Call-In Through REST And Composite APIs

Use remote call-in when an outside application owns the business process and needs Salesforce to respond. The caller might create leads from a partner portal, update cases from a service platform, or query account details during a back-office workflow. In this pattern, Salesforce exposes standard APIs or a purpose-built Apex REST service instead of polling the outside system.

Prefer standard Salesforce APIs when they already express the needed operation. REST resources cover common record work, while Composite API can group related requests and pass one subrequest result into a later subrequest. The Composite API reference documents up to 25 subrequests in one composite call and lets callers choose how dependent failures affect the request. That can reduce chatty Salesforce API integration traffic for small transactional groups without creating a custom Apex endpoint.

Use Apex REST when the contract should represent a business operation that doesn’t map cleanly to CRUD. Keep the service thin. Validate input, call domain logic, return a clear response, and avoid creating a second business layer that behaves differently from on-platform automation. Version the contract when changing request or response shapes in a way that could break clients.

Authentication and permissions deserve the same care as code. Use a dedicated integration identity or another supported OAuth model based on the ownership requirement. Grant only the object, field, and Apex access the client needs. Audit API usage and failed authentication so unusual behavior is visible.

This Salesforce integration pattern fits when the external platform owns timing and Salesforce is the service being called. If the caller needs to send thousands of records, switch from transactional REST to a bulk pattern rather than increasing request size until it becomes hard to recover.

Pattern: Batch Data Synchronization With Bulk API 2.0

Use batch synchronization when a large set of Salesforce records can move on a schedule or through a job without immediate user feedback. Common cases include nightly customer refreshes, large product loads, historical migrations, warehouse extracts, or regular updates from an ERP. Batch design favors throughput and restartability over instant response.

Bulk API 2.0 is the main Salesforce API integration choice for large asynchronous record jobs. Salesforce’s Bulk API 2.0 documentation supports asynchronous ingest and query jobs for large datasets, including insert, upsert, query, and delete operations. The job model lets the client submit work, check status later, and collect success or failure results without holding one HTTP request open for the whole load.

Upsert is especially useful for Salesforce data integration because external IDs can match source records to Salesforce records without first querying every Salesforce ID. Define those keys before the first load. A stable external key also makes reruns safer after partial failure. If the source changes the key semantics later, the synchronization design needs a migration plan rather than an ad hoc mapping fix.

Batch jobs need watermarks or another way to know what changed since the last successful run. A timestamp can work when the source guarantees dependable modification times. A source-side change table or event log is stronger when available. Store the last completed checkpoint only after the target confirms the job result, otherwise a failed run can create silent gaps.

Don’t use batch because it is familiar if the business needs near-real-time behavior. Likewise, don’t build event infrastructure for a job that runs once each night and finishes well inside its window. Match the pattern to the actual service level.

Pattern: Data Virtualization With Salesforce Connect

Use data virtualization when Salesforce users need current outside data but Salesforce does not need to own a copy. Instead of loading order history, inventory, or reference data into custom objects, Salesforce Connect can map supported external sources to external objects. Users and code can then access that data through Salesforce while the source remains elsewhere.

Virtualization removes reconciliation work because there is only one stored copy, but it moves dependency to request time. If the external source is slow or unavailable, the Salesforce experience that depends on it is also affected. That makes endpoint performance and availability part of the user experience. Cache only where the business can accept data that may be briefly out of date.

Salesforce documents external objects as real-time access to outside data through web service calls. The Salesforce Connect external object guidance also notes paging behavior and recommends filtering external queries so each interaction returns only what the user needs. That is important because treating an external object like a local table can create many remote requests and a slow page.

This pattern fits reference data, large history, and records that must stay in another system for ownership or storage reasons. It is a poor fit when Salesforce automation needs frequent local joins, heavy reporting, or dependable operation during source outages. In those cases, replication may be more practical.

Data virtualization can coexist with MuleSoft integration if MuleSoft exposes a standard endpoint over legacy data. The important choice is still whether Salesforce should store the data, not which connector happens to reach it.

Pattern: Bidirectional Synchronization With Clear Ownership Rules

Use bidirectional synchronization only when both Salesforce and another system must update part of the same business data. This is common with customer masters, product records, cases shared with service platforms, or quote-to-cash processes where separate applications own different stages. The technical connection is usually easy compared with conflict handling.

Start by assigning ownership at field level where needed. Salesforce may own account sales attributes while the ERP owns credit status and billing identifiers. If both systems can edit the same field, define which update wins, whether timestamps are trusted, and how users are told about rejected changes. “Last write wins” is simple but can hide lost updates when clocks differ or delayed jobs arrive out of order.

Prevent loops. An update from Salesforce to the external platform may trigger a return update that looks new to Salesforce. Use origin markers, integration user checks, message IDs, or version fields so the second system can recognize work it has already seen. Salesforce’s Platform Events subscription guidance describes several subscriber mechanisms, and event identifiers can support matching when events are part of the loop-control design. The same principle applies when Salesforce data integration uses APIs instead of events.

Choose transport per direction rather than forcing both directions through the same method. Salesforce might publish CDC outward while the other system writes changes back through REST or MuleSoft. That is still one logical synchronization process. The two directions can have different latency and volume needs.

Bidirectional Salesforce integration needs an operational reconciliation job even when real-time paths exist. Compare key records on a schedule, report mismatches, and give operators a safe repair path. Real-time delivery reduces delay, but it doesn’t remove the need to prove that both systems agree.

Operating All 9 Patterns Safely

Production integration fails at boundaries, so operational design must be part of every pattern. Any request or event that can be retried should carry a stable key that lets the receiver detect repeat delivery. A timeout can leave the caller unsure whether the remote side completed the operation, so duplicate-safe processing is essential.

Use this production checklist:

·        Retry timeouts and short outages with controlled backoff, but stop on bad credentials or invalid data.

·        Move permanent failures to an operator-visible queue with a correlation ID and enough context to reproduce the problem.

·        Keep secrets out of Apex and payloads, and restrict each integration identity to the fields it needs.

·        Use Named Credentials and External Credentials for outbound authentication setup instead of embedding it in code.

These rules apply across Apex callouts, MuleSoft integration, batch jobs, and event consumers.

Observability needs one correlation value that survives every hop. Put it in Salesforce logs or an integration tracking record, send it through MuleSoft, and pass it to the remote system when the contract allows. Record timestamps around remote calls so you can separate Salesforce processing time from network or remote service time. Metrics should cover failed transactions, retry counts, queue age, and batch completion rather than raw API volume alone.

Testing should cover failure paths as seriously as success. Mock remote responses for Apex tests, test expired tokens, replay duplicate events, stop a consumer and restart it, and load enough records to expose locking or timeout behavior. An external system integration isn’t proven because one happy-path record moved in a sandbox.

Choosing The Pattern That Matches The Failure You Can Accept

Strong Salesforce integration patterns make failure behavior obvious. Synchronous request and reply fails in front of the user. Fire-and-forget moves failure into a queue or job record. Events move processing to subscribers. Remote call-in puts timing in the outside caller. Batch moves recovery to job boundaries. Virtualization trades copied data for live dependency. Bidirectional sync requires conflict rules because both systems can write.

Choose ownership, timing, and recovery behavior before the tool. Then decide whether callouts, MuleSoft integration, events, standard APIs, Bulk API 2.0, or Salesforce Connect fit best. This is the core discipline behind useful Salesforce integration patterns, and it keeps Salesforce API integration code smaller with fewer hidden dependencies.

The 9 patterns can work together when each keeps a clear job. A user-facing Apex request can create an order, Salesforce Change Data Capture can publish later record changes, and middleware can route them downstream. A nightly reconciliation batch can catch mismatches. This combination works because each path has one reason to exist.

FAQs

What Are Salesforce Integration Patterns?

Salesforce integration patterns are repeatable ways to connect Salesforce with outside applications or data sources. They define who starts the exchange, whether the caller waits, where data is stored, and how failures are handled. The same business need can use Apex, MuleSoft, standard APIs, events, or Salesforce Connect. The pattern should come from timing, ownership, and recovery needs rather than from a preferred tool.

Which Pattern Fits Real-Time User Actions?

Use synchronous request and reply when the current Salesforce action cannot finish without an outside answer. Inventory checks, tax calculations, and payment authorization are common examples. Keep the remote chain short because every dependency adds delay and another failure point. When later completion is acceptable, an asynchronous pattern usually gives users a more dependable experience. This is one of the most important Salesforce integration patterns to separate early.

When Should I Use Apex Callouts Instead Of MuleSoft?

Use direct callouts when Salesforce needs a small number of clear HTTP endpoints and the logic belongs close to Salesforce. Use middleware when several systems share the same contract, messages need major mapping or routing, or protocol differences should stay outside the org. The decision is about system responsibility. If Apex becomes the central router for many unrelated platforms, the boundary is usually misplaced.

When Does MuleSoft Make Sense For Salesforce?

MuleSoft makes sense when Salesforce is one participant in a wider process and a shared layer needs to coordinate systems, expose stable APIs, or reshape messages outside the org. It can also keep legacy protocol details away from Salesforce code. It adds another runtime to operate, so it should solve a real cross-system need rather than sit between Salesforce and every endpoint by default.

What Is The Difference Between Platform Events And Salesforce Change Data Capture?

Platform Events carry business events that you define. Salesforce Change Data Capture reports Salesforce record changes. Use a custom event when subscribers care that a business milestone occurred. Use Salesforce Change Data Capture when another platform needs record-level synchronization. Both can feed outside subscribers, but they create different contracts and should not be treated as interchangeable.

Is Pub/Sub API The Preferred Choice For New Event Clients?

For new event-driven clients, Salesforce currently directs architects toward Pub/Sub API and describes CometD-based Streaming API as a legacy path for new designs. Pub/Sub API supports Platform Events and Salesforce Change Data Capture through gRPC and HTTP/2. Existing Streaming API clients may still run, but new work should evaluate Pub/Sub API first and confirm that client language, network policy, and operations fit the environment.

When Should I Use Bulk API 2.0?

Use Bulk API 2.0 for large asynchronous loads, extracts, migrations, or scheduled record updates. Its job model lets a client submit work, check status later, and collect results without holding one request open. Smaller transactions that need an immediate answer usually fit REST or Composite API better. Volume, timing, and restart needs should decide the choice.

What Is The Main Risk In Bidirectional Synchronization?

The main risk is unclear ownership. If Salesforce and another platform can change the same field without a conflict rule, delayed updates can overwrite newer values or create loops. Define ownership by object or field, identify the origin of each update, and run reconciliation checks. Good Salesforce integration patterns make those rules visible instead of hiding them inside mapping code.

How Do Named Credentials Help Apex Integration?

Named Credentials let code use a logical endpoint while Salesforce keeps endpoint and authentication setup outside the business logic. The newer model works with External Credentials to define authentication and permitted principals. This makes environment changes easier and reduces hard-coded secrets. Permission design still matters because the user or integration identity must be allowed to use the credential.

Can Salesforce Connect Replace Data Synchronization?

Salesforce Connect can replace replication when users need live outside data and Salesforce does not need a stored copy. The tradeoff is runtime dependence on the remote source. If the source slows down or becomes unavailable, the Salesforce feature using that data is affected. Local replication may still fit better when reporting, automation, or offline operation needs a Salesforce copy.

How Should I Prevent Duplicate Processing?

Use stable business keys or idempotency keys so repeated delivery produces the same business result. Keep processed message identifiers where needed and use durable external IDs for upserts. This matters for queues, events, and Salesforce API integration because a timeout can leave the sender unsure whether the first request completed. Retrying safely is better than assuming every request is delivered exactly once.

Should Every Salesforce Connection Use MuleSoft?

No. A direct call may be clearer for a narrow Salesforce-owned requirement. Bulk API 2.0 may fit a large data job, Salesforce Connect may fit live external data, and Pub/Sub API may fit event subscribers. Middleware is useful when there is shared orchestration or policy to own. One of the core Salesforce integration patterns principles is to avoid extra runtime layers that do not solve a defined problem.

How Do I Choose Between REST API And Composite API?

Use REST when operations are independent or naturally occur one at a time. Use Composite API when several related Salesforce operations belong in one client request and later steps depend on earlier results. Composite reduces round trips, but it is not a large-volume batch tool. Salesforce API integration should move to Bulk API 2.0 when record count is the main concern.

How Should Integration Errors Be Monitored?

Track failed jobs, remote response codes, event-consumer failures, middleware errors, and batch results where operators can act on them. Carry one correlation ID across systems. Separate temporary transport failures from permanent data or permission errors because the recovery path differs. Strong Salesforce integration patterns define this operational path before production rather than adding logging after incidents occur.

Can Several Patterns Be Used In One Business Process?

Yes. One process may use a synchronous request for an immediate order number, Salesforce Change Data Capture for later record updates, and Salesforce API integration for inbound shipment status. A batch job can reconcile key records overnight. Combining Salesforce integration patterns is reasonable when each path has one clear purpose and all paths follow the same ownership and recovery rules.