Salesforce's Six Patterns, in My Words

Module 3 of 7 in the chapter Integration Patterns, chapter 7 of the Integration Architect course. Each module stands on its own. Previous: Call-Outs and Call-Ins · Next: Publish and Subscribe

The question this module answers: What does each of Salesforce’s six integration patterns mean, and how would you say it to a team?

These are the words on the exam, and you should be able to speak every one of them. Not recite them: speak them, so that a developer hears the name and knows what to build. So here are Salesforce’s six, each with Salesforce’s own definition, then how I say it, then where you’d meet it at Steve Trucking.

Salesforce’s guide also says which mechanisms fit each pattern best today. I give you those, dated, because they change. The pattern doesn’t.

Click to enlarge

The six, at a glance.

Request and Reply

Salesforce’s words: Salesforce “invokes a process on a remote system, waits for completion of that process, and then tracks state based on the response” (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01).

My words: it’s a request, and it’s a wait. It’s a synchronous interaction between two systems. The client sends the request, and its processing, the thread, is held until the response comes back.

At Steve Trucking, it’s the balance check from module 1: the person at the order screen can’t go on until the balance comes back.

Salesforce’s best fit today is External Services, which calls a REST API without code, with the HTTP callout action in Flow as a good second, and Apex callouts when you need code. Every one of them is a call-out, and every one waits.

Fire and Forget

Salesforce’s words: Salesforce “doesn’t wait for completion of the process. Instead, the remote process receives and acknowledges the request and then hands off control back to Salesforce.”

My words: you make the request, and you don’t need the answer. The thread releases itself. The data goes on a journey, and you don’t wait for it. With a platform event, once the event goes out, you’re done; you move on. And remember module 1: you get a receipt, not the outcome.

At Steve Trucking, it’s the late delivery: Redrock needs to know, and Salesforce doesn’t need to wait while it finds out.

Salesforce’s best fit today is a platform event published from Flow, or from Apex when you need code, with Pub/Sub API for the systems that consume it, and Change Data Capture when the event is simply “this record changed”.

A little history, because you’ll meet it. Before platform events, the classic fire and forget was the outbound message: an insert or update in Salesforce sent a SOAP message to one endpoint. If the other side didn’t send back a positive acknowledgment, Salesforce tried again, so it was “a form of guaranteed delivery”, in Salesforce’s words. Plenty of orgs still have them. Salesforce now calls it “a legacy way of integration” and says: “All new solutions should use Flow with Pub/Sub API.” So if you find outbound messages in an org, you know what they are, and you know which way the design is going.

Batch Data Synchronization

Salesforce’s words: data in Salesforce “is created or refreshed to reflect updates from an external system”, and changes from Salesforce are sent out; “Updates in either direction are done in a batch manner.”

My words: this is data replication. You’re keeping two systems in step, in bulk, usually at the data layer, not one record at a time as people work. Changes in Salesforce going out to your data warehouse. Your ERP’s accounts updated every night. New products or new pricing coming in.

At Steve Trucking, say the delivery counts go to Finance every night, so it can invoice the partners. Nobody is waiting on a screen for that; it just has to be complete in the morning.

Salesforce’s best fit today is an ETL tool that reads the changes and loads them with the Bulk API. Salesforce rates calling in, or calling out, record by record as suboptimal for this pattern: it’s the wrong shape for bulk.

Remote Call-In

Salesforce’s words: data in Salesforce “is created, retrieved, updated, or deleted by a remote system.”

My words: an external system is calling in. That’s module 2, and remember who counts: any external client, even your own middleware.

At Steve Trucking, it’s FleetLink sending the latest position, and our integration layer upserting the partners’ manifests.

Salesforce’s best fit today is Salesforce’s own APIs: REST, Composite, GraphQL, and Bulk API 2.0 for volume. Or the caller doesn’t send a record at all: it publishes an event onto Salesforce’s event bus through Pub/Sub API, which Salesforce calls “the recommended way for external publishers to publish events”. Say FleetLink published a “position changed” event, and a flow in Salesforce acted on it. FleetLink still opens the connection, so it’s still a call-in. The SOAP API and custom Apex web services still work, and Salesforce rates them suboptimal for new work. Chapter 8 takes them one at a time.

UI Update Based on Data Changes

Salesforce’s words: “The Salesforce user interface must be automatically updated as a result of changes to Salesforce data.”

My words: a strange little name, but it means I’m looking at a page, something happens, and the page updates. I don’t press refresh.

How would you have done that years ago? Little timers. Every minute, the page makes a call and checks whether the data has changed. That’s polling, and most of those calls come back with nothing. Now Salesforce sends an event when the data changes, and the screen redraws itself, without the overhead of polling.

Click to enlarge

Frame 1 of 2: polling. The screen keeps asking.

Click to enlarge

Frame 2 of 2: an event. The screen is told.

At Steve Trucking, a dispatch coordinator has today’s deliveries open. A delivery is marked late, and it turns late on the coordinator’s screen, without a refresh.

Salesforce’s recommended solution is a platform event, published from a trigger or a flow when the data changes, and a component on the page that listens for it. Salesforce’s own list of limits matters here: “Delivery of notifications isn’t guaranteed. Order of notifications isn’t guaranteed. Notifications aren’t generated from record changes made by Bulk API.” So it’s for keeping a screen current, not for anything that must never be missed.

A little history. The older way to push changes to a page was the Streaming API. Salesforce now lists it as legacy and points to Pub/Sub API.

Data Virtualization

Salesforce’s words: Salesforce “accesses external data in real time. This removes the need to persist data in Salesforce and then reconcile the data between Salesforce and the external system.”

My words: you don’t bring the data on core. You see it, and you discard it. It’s always live, because it never stops living in the other system. You don’t persist it; you don’t save it.

At Steve Trucking, say the older deliveries live in an archive in Snowflake. A care agent needs one from three years ago, on the case in front of them. With virtualization, it’s on the screen, read from Snowflake as the page opens, and it’s never copied back into Salesforce.

Salesforce’s best fit today is Salesforce Connect: external objects that look like custom objects, mapped to tables outside Salesforce, through adapters such as OData and one for Snowflake. “Accessing an external object fetches the data from the external system in real time.”

Or you could build a little Lightning web component that makes a call-out, brings the data back, puts it on the screen and throws it away. I call that poor person’s virtualization: the simple, low-cost version, built by hand. Same pattern, a different mechanism.

Copy It, or See It

Batch data synchronization and data virtualization answer the same need, data from another system in front of your users, in opposite ways.

Click to enlarge

Copy it, or see it.

Copy it, and it’s yours: fast, reportable, and as old as the last run. See it, and it’s always current, but every look is a call, and if the other system is down, so is your page. Module 5 is how you choose.

Test knowledge. Know the six patterns by name and what each one means: Request and Reply (Salesforce calls out and waits); Fire and Forget (Salesforce calls out and gets an acknowledgment, not the outcome); Batch Data Synchronization (bulk replication, either direction); Remote Call-In (another system creates, reads, updates or deletes Salesforce data); UI Update Based on Data Changes (the screen updates itself, no polling); Data Virtualization (external data in real time, not stored in Salesforce). Know the three kinds, process, data and virtual, and which pattern is synchronous and which asynchronous.

What an Architect Decides Here

• For every arrow, the pattern by its Salesforce name, so the team knows what to build.
• For every request and reply: what the person or process does while it waits, and if no answer comes.
• For every fire and forget: what the receipt tells you, and who finds out when the outcome fails.
• For every flow of data from another system: copy it, or see it.
• For any legacy mechanism you find (an outbound message, the Streaming API): what it is, and where Salesforce says the design is going.

Beyond the exam: what AI changes. An agent that looks something up in another system while a person waits is request and reply, whatever it’s called. An agent that answers from data it was given last night is answering from a batch copy, and it’s as fresh as the last run. And grounding an agent in data that’s read live, and never copied, is data virtualization. So when someone shows you an agent, ask which pattern each of its calls is, and the rest of this chapter applies.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): each pattern’s context, problem, forces and solution table, and the legacy table, checked 2026-11-01.