December 16, 2024
Salesforce integration patterns are the proven ways to connect Salesforce with other systems, and the main ones are request and reply, fire and forget, batch data synchronization, remote process invocation, data virtualization, and publish and subscribe. Each fits a different need, from real-time calls to scheduled bulk syncs to event-driven messaging. Pick the pattern that matches your timing and data needs, pair it with the right Salesforce API, and follow a few security and reliability practices, and your integrations stay fast, safe, and easy to maintain. This guide walks through every pattern, the APIs behind them, and the best practices that keep them running.
Whether you are connecting an ERP, a marketing platform, or a legacy system, the right pattern makes the difference between an integration that scales and one that breaks under load. Our Salesforce integration team uses these patterns on enterprise projects every day, and the sections below share how to choose between them.
An integration pattern is a reusable blueprint for moving data or triggering actions between Salesforce and another system. Instead of inventing a new approach for every connection, you match your need to a known pattern that already solves it. That saves time, avoids common mistakes, and makes your architecture easier for the next person to understand.
The right pattern depends on three questions: does the data need to move in real time or on a schedule, does Salesforce need an answer back or not, and how many systems are involved. Answer those, and the pattern usually picks itself. Getting this choice right up front is what separates a clean integration architecture from a tangle of one-off connections.
Before the patterns, it helps to know the shapes an integration can take at the architecture level. How you wire systems together sets the ceiling on how far your integrations can scale. The table compares the main styles.
| Architecture Style | How It Works | Best For |
|---|---|---|
| Point-to-point | Each system connects directly to each other one | A few simple, stable connections |
| Hub-and-spoke | Systems connect through a central hub or middleware | Several systems that share data |
| API-led connectivity | Reusable APIs in layers (system, process, experience) | Enterprise scale and reuse across teams |
| Event-driven | Systems react to events published on a bus | Real-time, loosely coupled integrations |
Point-to-point is fine for a couple of stable connections, but it turns into a tangle as systems multiply. Hub-and-spoke and API-led connectivity route traffic through middleware, so each system connects once and reuses shared services. Event-driven architecture adds a message bus so systems react to changes without waiting on each other. Most enterprise orgs end up blending these, and clear write-ups on Salesforce Developers cover the reference architectures in depth.
Salesforce documents a set of canonical integration patterns, and almost every real-world connection maps to one of them. The table sums them up, and the sections below add the detail behind each.
| Pattern | What It Does | Timing |
|---|---|---|
| Request and reply | Salesforce calls a system and waits for an answer | Synchronous |
| Fire and forget | Salesforce sends a message and moves on | Asynchronous |
| Batch data synchronization | Bulk data moves on a schedule | Asynchronous |
| Remote process invocation | Salesforce triggers an action in another system | Sync or async |
| Data virtualization | Salesforce reads external data live, without storing it | Real-time on demand |
| Publish and subscribe | Systems react to events as they happen | Near real-time, event-driven |
Request and reply is a synchronous call: Salesforce sends a request to another system and waits for the answer before moving on. It suits anything that needs an immediate response, like checking a payment, validating an address, or pulling a live credit score. The trade-off is that Salesforce waits, so the external system has to be fast and reliable.
Fire and forget is the asynchronous cousin: Salesforce sends a message and does not wait for a reply. It is ideal for actions where an instant answer does not matter, like logging an activity to an analytics tool. Because Salesforce does not block, this pattern keeps the user experience fast and reduces dependencies between systems.
Batch data synchronization moves large volumes of data on a schedule rather than record by record. It is the right choice for syncing product catalogs, nightly ERP updates, or any bulk transfer where real time is not required. Batching keeps you well within API limits and is far more efficient than thousands of single calls. Learn how to solve common Salesforce data synchronization challenges.
Remote process invocation lets Salesforce trigger a process in another system, such as kicking off an order in an ERP. Data virtualization goes the other way: Salesforce reads and displays external data live, without ever storing it, which is perfect for showing real-time inventory or order status inside a Salesforce screen. Practical examples on Apex Hours show how teams implement both.
Publish and subscribe is the modern default for real-time, loosely coupled integration. Salesforce publishes an event, and any number of systems subscribe and react, with no direct connection between them. This is how you keep several systems in sync as things happen, without the brittle chains of point-to-point calls, and it is where much of Salesforce's newer tooling is focused.
Every pattern is either synchronous, where Salesforce waits for a response, or asynchronous, where it does not. Getting this choice right is one of the most important decisions in any integration. Synchronous is simple and gives an immediate answer, but it ties Salesforce's performance to the other system, and a slow partner can stall your users.
Asynchronous integration decouples the systems, so Salesforce keeps working while the other system catches up. It scales better and survives outages more gracefully, at the cost of a little added complexity in tracking state. As a rule, reach for synchronous only when a user truly needs an answer right now, and lean asynchronous everywhere else. That single habit prevents most integration performance problems.
Patterns describe the approach; Salesforce APIs are how you actually build them. Salesforce offers a rich set, and matching the API to the pattern is what keeps an integration efficient. The table maps the main ones.
| API | Best For | Style |
|---|---|---|
| REST API | Everyday record access and web or mobile apps | Synchronous |
| SOAP API | Formal contracts and older enterprise systems | Synchronous |
| Bulk API | Loading or extracting millions of records | Asynchronous |
| Composite API | Several related calls in one round trip | Synchronous |
| GraphQL API | Fetching exactly the fields you need | Synchronous |
| Streaming API | Pushing updates to subscribers | Event-driven |
| Platform Events | Custom event messages between systems | Event-driven |
| Change Data Capture | Streaming record changes as events | Event-driven |
REST and SOAP APIs cover everyday synchronous access, the Bulk API handles high-volume loads, and the Composite API bundles related calls to save round trips. The GraphQL API lets you fetch exactly the fields you need. On the event side, the Streaming API, Platform Events, and Change Data Capture push updates to subscribers in near real time. Our deep dive on Salesforce API integration compares these options in more detail, and reference guides on Jitendra Zaa's blog show them in working code.
Event-driven integration deserves a closer look, because it is where modern Salesforce architecture is heading. Platform Events let you define custom event messages that Salesforce and external systems publish and subscribe to, so systems communicate through a shared bus instead of direct calls. Change Data Capture streams record changes automatically, so any subscriber can react the moment data updates in Salesforce.
The payoff is loose coupling: each system only needs to know about the events, not about every other system. That makes the whole architecture easier to change, because you can add or replace a subscriber without touching the publisher. For high-volume, real-time needs, this event-driven approach scales in ways that request-by-request integration cannot.
As the number of systems grows, wiring them directly becomes unmanageable. Middleware solves this by sitting between systems and handling routing, transformation, and orchestration in one place. The MuleSoft Anypoint Platform is the common choice in the Salesforce world, and it enables API-led connectivity: building reusable APIs in layers so the same service can be used across many projects.
This approach turns integration from a series of one-off builds into a library of reusable building blocks. A well-designed set of APIs pays off every time a new project reuses one instead of building from scratch. If you are connecting Salesforce to an ERP or several back-office systems, our guide to the MuleSoft Salesforce connector walks through the setup.
Choosing the right pattern is half the job; building it well is the other half. A few practices separate integrations that hold up from ones that break quietly. The table sums them up.
| Best Practice | What To Do | Why It Matters |
|---|---|---|
| Secure every connection | Use OAuth, named credentials, and least privilege | Protects data and passes audits |
| Respect the limits | Design around API rate and governor limits | Keeps integrations from failing at scale |
| Handle errors and retries | Log failures and retry safely | No silent data loss |
| Monitor and log | Track every integration with alerts | Catch issues before users do |
| Keep it loosely coupled | Use reusable APIs and middleware | Change one system without breaking the rest |
Security comes first. Use OAuth for authentication, store credentials in named credentials rather than in code, and grant each integration only the access it needs. Encrypt data in transit, lock down endpoints, and keep compliance requirements like GDPR in view from the start.
Salesforce enforces API rate limits and governor limits, so design around them with bulk patterns and efficient calls rather than hitting them at scale. Build real error handling with safe retries and clear logging, so a failed call is caught and recovered instead of lost. Then monitor every integration with alerts, so you learn about a problem before your users do. Thoughtful engineering here is what makes an integration reliable. Setup notes on SFDCPanther cover error handling and retry patterns in practice.
Favor loose coupling through reusable APIs and middleware, so you can change one system without breaking the others. Version your APIs, govern how they are used, and test integrations thoroughly before and after every release. Disciplined Salesforce development practices here keep a growing set of integrations maintainable rather than fragile.
Minuscule Technologies helps enterprises across banking, manufacturing, healthcare, real estate, and aviation design and build Salesforce integrations that scale. The work starts with the architecture: choosing the right patterns, APIs, and middleware for how your systems actually work, rather than forcing a one-size-fits-all approach.
Because the team comes from an engineering background, integration architecture, security, error handling, and monitoring are built in from the start, not bolted on later. That means your integrations stay fast, secure, and reliable as data volumes climb and new systems join the picture, with reusable APIs that make the next project easier than the last.
They are reusable blueprints for connecting Salesforce with other systems. The main ones are request and reply, fire and forget, batch data synchronization, remote process invocation, data virtualization, and publish and subscribe.
Synchronous means Salesforce waits for a response before continuing, which suits real-time needs. Asynchronous means it sends a message and moves on, which scales better and decouples the systems. Most integrations should lean asynchronous.
It depends on the job: REST and SOAP for everyday access, Bulk for high-volume loads, Composite to bundle calls, GraphQL for precise queries, and Streaming, Platform Events, and Change Data Capture for event-driven, real-time integration.
It uses Platform Events and Change Data Capture so systems publish and subscribe to events instead of calling each other directly. This keeps systems loosely coupled and supports real-time updates at scale.
API-led connectivity builds reusable APIs in layers, usually through middleware like MuleSoft, so the same service can be reused across many integrations instead of being rebuilt each time.
Use OAuth for authentication, store secrets in named credentials, grant least-privilege access, encrypt data in transit, and keep compliance requirements in view. Add monitoring and logging so any security issue is caught quickly.
The right Salesforce integration patterns give you connections that are fast, secure, and easy to maintain as your business grows. Choosing well up front, and building with real engineering discipline, is what keeps your systems working together for years rather than months. You do not have to design it alone. Minuscule Technologies picks the right patterns and APIs, builds the middleware and security around them, and monitors every connection so your data flows cleanly. Talk to our Salesforce integration experts today, and let's connect your systems the right way.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
Plot No. 4, Sridevi Amman Street, Perumal Nagar Extension, Old Pallavaram, Chennai, Tamil Nadu 600117, India.
