The Six Salesforce Integration Patterns and When to Use Each

Salesforce defines six integration patterns, not five. Its Integration Patterns and Practices guide lists two Remote Process Invocation patterns (Request and Reply, and Fire and Forget) and Batch Data Synchronization. The other three are Remote Call-In, UI Update Based on Data Changes and Data Virtualization. Pick by two questions Salesforce itself uses. Which system starts the call, and does the caller wait for the answer?

The guide was written for a company integrating its own org. A SaaS company has a harder version of the problem, because your product has to work inside hundreds of customer orgs you don't control, each with its own API allocation, security settings and admin. In that setting the pattern also decides whether you can ship from your own servers or need a managed package installed in every customer org. Appnigma builds these customer-facing integrations for B2B SaaS companies. Our done for you delivery builds and maintains the integrations your customers ask for, and our marketplace apps work puts your product inside Salesforce when the pattern needs code in the customer's org.

Updated October 2026. Checked against Salesforce's Integration Patterns and Practices guide (Winter '27, API version 68.0), the Apex Developer Guide and the Salesforce Developer Limits reference. The earlier version said there were five patterns, counted "event driven" and "UI integration" as patterns, left out Remote Call-In and Data Virtualization, and listed REST and SOAP as the tools for Salesforce calling out. This update corrects those and adds the managed package question, per-org API arithmetic and current status for PushTopic events and Connected Apps.

The six patterns at a glance

Salesforce sorts every pattern by direction, then by type (process, data or virtual) and timing (synchronous or asynchronous), in its Pattern Selection Guide. In the table below, the best-fit column uses the solutions the guide rates Best. The last column is our reading of where a vendor's code has to run when the Salesforce org belongs to your customer.

Each scenario comes from the guide's Pattern Summary. Salesforce notes that "each pattern describes the design and approach for a particular scenario rather than a specific implementation," so a real integration usually combines two or three of them.

When Salesforce calls your product

Request and Reply covers the case where "Salesforce invokes a process on a remote system, waits for completion of that process, and then tracks state based on the response." A rep clicks a button on an Opportunity and sees a price or a credit check from your product. The guide rates Enhanced External Services and Apex callouts from a Lightning component or Visualforce page as Best. Callouts made from a trigger are Suboptimal, because "all calls made from within the trigger context must execute asynchronously from the initiating event."

The timing budget is tight. A single Apex transaction can make "a maximum of 100 callouts," the default timeout "is 10 seconds," and the cumulative maximum per transaction "is 120 seconds," per Callout Limits and Limitations. For a slow API the guide recommends a continuation, which it describes as "an asynchronous callout." For a vendor, the practical rule is that an endpoint Salesforce calls synchronously needs a response time you can promise across every customer at once, not an average.

Fire and Forget is the version where Salesforce "doesn't wait for completion of the process." The guide rates process-driven platform events Best, with outbound messaging and Apex-published events rated Good. The two behave differently when your endpoint is down. Outbound messaging "retries for up to 24 hours" when it gets no acknowledgment. Platform events "are only published to the bus once. There is no retry on the Salesforce side." With platform events your subscriber has to come back and replay what it missed, and Salesforce keeps platform events and change events "for 72 hours," per Event Message Durability. The guide labels the outbound messaging option "workflow-driven." Salesforce ended support for Workflow Rules on December 31, 2025, per this Help article. Build new triggers in Flow.

Remote Call-In is where most SaaS integrations live

Remote Call-In is the pattern where "data stored in Lightning Platform is created, retrieved, updated, or deleted by a remote system." In a customer-facing integration your product is that remote system. When your app writes usage back to an Account or reads Opportunities to score them, it is calling into the customer's org. The guide rates REST API and SOAP API Best, Bulk API 2.0 "optimal for bulk operations," and custom Apex web services Suboptimal unless you need one transaction across several objects.

Two lines in that page shape the design. REST and SOAP calls are synchronous, and "asynchronous calls to Salesforce aren't supported," though Bulk API 2.0 processes the data asynchronously after you submit it. And "any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0." Below that, Salesforce recommends bulkified REST calls such as Composite, where a request is "limited to 200 records." Our guide to Bulk API 2.0 limits and batching covers the job side.

Every one of those calls is billed to the customer. Salesforce states that "API calls made from installed managed packages, count against your org limit" in its limits reference. An Enterprise Edition org gets 100,000 requests per 24 hours plus 1,000 per Salesforce license, per API Request Limits and Allocations. Here is arithmetic from those documented figures, not a measured customer. An Enterprise org with 50 Salesforce licenses has 150,000 requests a day. If your product pushes 20,000 changed records a day at one record per request, it spends about 13 percent of the org's budget. Everything else the customer runs shares the rest. Sent as 200-record collections, the same work is 100 requests. The same page caps "concurrent inbound requests (calls) with a duration of 20 seconds or longer" at 25 in production orgs, which matters when your workers fan out across one large customer. Our post on cutting Salesforce API calls with Composite and GraphQL goes further.

Batch Data Synchronization and Change Data Capture

Batch Data Synchronization covers data that is "created or refreshed to reflect updates from an external system," and changes sent out, with "updates in either direction... done in a batch manner." The guide rates Change Data Capture Best when Salesforce owns the data and a third-party ETL tool Best when the remote system owns it. It rates both call-in and callout approaches Suboptimal here because they create "considerable on-going traffic between the two systems."

Change Data Capture (CDC) is the stream Salesforce publishes whenever a selected object's records change. For a vendor it is usually a better outbound feed than polling with SOQL. It has its own budget. Enterprise orgs get 25,000 delivered events per 24 hours, and "the event delivery allocation is shared between high-volume platform events and Change Data Capture events," per Default Platform Event Allocations. You package the object selections through a custom channel, and the five-selection cap doesn't apply to "AppExchange released managed packages," per Change Data Capture Allocations. The detail is in our comparison of platform events and Change Data Capture.

UI Update and Data Virtualization

UI Update Based on Data Changes is for a screen that "must be automatically updated as a result of changes to Salesforce data," such as a support rep seeing a payment land while on a call. The guide's recommended solution is Streaming API with a PushTopic, and it warns that "delivery of notifications isn't guaranteed." Newer Salesforce docs have moved on. "PushTopic and generic events are legacy products," and Salesforce suggests Change Data Capture instead of PushTopic events, per Streaming Event Features. For a vendor this pattern is a Lightning component in your package that subscribes to CDC or platform events. Each logged-in user on that component "counts as one concurrent client."

Data Virtualization is the one pattern that copies nothing. "Salesforce accesses external data in real time," and the guide rates Salesforce Connect Best, mapping your tables to external objects through OData or a custom Apex Connector Framework adapter. It fits large or fast-changing data that users only need to look at, such as invoice history. The external system has to answer inside "a configurable 120-second maximum timeout," and the customer sets up Salesforce Connect in their own org, so confirm their edition and licensing before you promise it in a deal.

Is event-driven integration a Salesforce integration pattern?

No. Event Driven Architecture is a section of Salesforce's guide, not a seventh pattern. The section explains that platform events, Streaming API and Change Data Capture are "covered in this document as part of the existing pattern structure." Events show up inside Fire and Forget, Batch Data Synchronization, Remote Call-In and UI Update as one of the solutions. Many guides and AI answers list "event driven" as a pattern of its own, and that is where the "five patterns" lists come from.

The distinction matters when you design. Calling something "event driven" doesn't settle who retries, which budget it spends or where the subscriber runs. Naming the actual pattern, for example Fire and Forget with platform events, does. For new subscribers outside Salesforce, Salesforce now recommends Pub/Sub API "if you're writing an app for publishing and subscribing to platform events and change data capture events," per Getting Started with Streaming API.

Which patterns need a managed package in the customer's org

A pattern where Salesforce starts the call needs your code inside the customer's org. Request and Reply, Fire and Forget with platform events, and UI Update all depend on Apex, flows or components that have to be installed. That means a managed package, which has to pass the AppExchange security review before you list it. Remote Call-In and ETL-style Batch Data Synchronization can run entirely from your servers, so you can often start with an OAuth connection and add a package later.

A packaged Apex callout to your product still needs setup in each customer org after install. An Apex callout fails unless the endpoint is in Remote Site Settings or the callout uses a named credential, per Adding Remote Site Settings. You can package the named credential, external credential and permission set, but "external credential certificates and access tokens aren't packageable," per Package Named Credentials. Each customer authenticates once after install, and that step belongs in your onboarding flow. Our explainer on named credentials and external credentials shows the setup.

Salesforce changed how a new integration gets its OAuth app in Spring '26. "Starting in the Spring '26 release, you can't create new Connected Apps. Use ECAs instead," per Salesforce's ISVforce guide. Existing connected apps keep working. A new integration should start on an External Client App, and our guide to External Client App OAuth for SaaS products walks through it. For the connecting user, Salesforce's Integration user license limits a system user "to API-only operations," which our post on the integration user license and setup covers.

How to choose a pattern for a customer-facing integration

Start from what the customer's user or admin experiences, then map it to a pattern. If a user is waiting on a Salesforce screen for your product's answer, it is Request and Reply, and your API latency becomes part of their page load. If your product needs to hear about Salesforce changes within seconds, use Fire and Forget with platform events, or Change Data Capture when the trigger is just a record changing. If your product writes into Salesforce, it is Remote Call-In, with Bulk API 2.0 above 2,000 records.

A common shape for a SaaS integration is Remote Call-In plus CDC. Your servers write through REST or Bulk API, and change events tell you what to read back. That pairing ships without code in the customer's org except a packaged channel, and it spends two budgets you can estimate per customer before signing. Add Request and Reply or UI Update when a buyer asks to see your data on their record pages, because that is the point where you need a managed package.

The choice is expensive to reverse after launch. Moving a nightly batch to event-driven means new retry logic, a replay store and different monitoring, because none of the old assumptions about timing survive. If you would rather not run that across every customer org yourself, Appnigma's integration infrastructure lets your engineers deploy integrations on our infrastructure with monitoring per customer connection.

Mistakes that show up after customers install

• Calling out from a trigger. The guide rates it Suboptimal, and a trigger callout has to be asynchronous anyway.
• Treating platform events as guaranteed delivery. Salesforce publishes once, so a subscriber that misses the 72-hour window loses events.
• Budgeting CDC and platform events separately. They draw on one delivery allocation per org.
• Sending one record per REST call. Above 2,000 records Salesforce points you to Bulk API 2.0.
• Assuming an AppExchange listing exempts your calls from API limits. Managed package calls count against the customer's org limit.
• Building new subscribers on PushTopic events, which Salesforce now labels legacy.

Frequently Asked Questions

How many Salesforce integration patterns are there?

Six, per Salesforce's Integration Patterns and Practices guide. Request and Reply and Fire and Forget cover Salesforce calling out. Batch Data Synchronization, Remote Call-In, UI Update Based on Data Changes and Data Virtualization cover the rest.

Which Salesforce integration pattern is best for high volume data?

Batch Data Synchronization, using Change Data Capture outbound or an ETL tool inbound. For writes into Salesforce, Salesforce calls any operation over 2,000 records a good candidate for Bulk API 2.0.

Are remote calls into Salesforce synchronous?

REST and SOAP API calls are synchronous. Bulk API 2.0 accepts the job synchronously and processes the data asynchronously, and publishing a platform event lets the remote side move on without waiting.

Do API calls from a managed package count against the customer's limits?

Yes. Salesforce states that API calls made from installed managed packages count against the org's limit, and no general exemption exists for AppExchange apps.

Can Appnigma build our customer-facing Salesforce integration?

Yes. Appnigma's done for you delivery builds and maintains the integrations your customers ask for, and marketplace apps covers the managed package and listing when the pattern needs code inside the customer's org.

Related Articles

• Salesforce Bulk API 2.0 Guide
• Platform Events vs Change Data Capture
• Composite and GraphQL API
• Named Credentials and External Credentials
• External Client App OAuth 2.0
• Salesforce Integration User License and Setup

Sources

1. Salesforce Developers, Integration Patterns and Practices, Pattern Summary
2. Salesforce Developers, Integration Patterns and Practices, Pattern Selection Guide
3. Salesforce Developers, Integration Patterns and Practices, Remote Process Invocation Request and Reply
4. Salesforce Developers, Integration Patterns and Practices, Remote Process Invocation Fire and Forget
5. Salesforce Developers, Integration Patterns and Practices, Batch Data Synchronization
6. Salesforce Developers, Integration Patterns and Practices, Remote Call-In
7. Salesforce Developers, Integration Patterns and Practices, UI Update Based on Data Changes
8. Salesforce Developers, Integration Patterns and Practices, Data Virtualization
9. Salesforce Developers, Integration Patterns and Practices, Event Driven Architecture
10. Salesforce Developers, Apex Developer Guide, Callout Limits and Limitations
11. Salesforce Developers, Apex Developer Guide, Adding Remote Site Settings
12. Salesforce Developers, Salesforce Developer Limits and Allocations, API Request Limits and Allocations
13. Salesforce Developers, Platform Events Developer Guide, Default Platform Event Allocations
14. Salesforce Developers, Change Data Capture Developer Guide, Change Data Capture Allocations
15. Salesforce Developers, Pub/Sub API Developer Guide, Event Message Durability
16. Salesforce Developers, Streaming API Developer Guide, Streaming Event Features
17. Salesforce Developers, Streaming API Developer Guide, Getting Started with Streaming API
18. Salesforce Developers, Named Credentials Developer Guide, Package Named Credentials
19. Salesforce Developers, ISVforce Guide, Secure Your Connected Apps and External Client Apps
20. Salesforce Developers, REST API Developer Guide, Supported Editions and Integration User License
21. Salesforce Help, Workflow Rules and Process Builder End of Support