Choosing a Pattern
Questi contenuti non sono ancora disponibili nella tua lingua.
Module 5 of 7 in the chapter Integration Patterns, chapter 7 of the Integration Architect course. Each module stands on its own. Previous: Publish and Subscribe · Next: Several Patterns, One Solution
The question this module answers: Given an arrow and its requirements, how do you choose its pattern?
Chapter 6 ended with the shape of every arrow: who starts it, from where to where, how soon, and how much. The order was shape first, then pattern, then mechanism. This module is the middle step. And Salesforce gives you a tool for it: two selection tables in its Integration Patterns guide.
Three Questions
Section titled “Three Questions”The tables ask three questions. You already have the answers from chapter 6.
Which way does it go? From Salesforce to another system, or from another system to Salesforce. That’s module 2: who opens the connection.
What kind of integration is it? Salesforce sorts them into three kinds (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01):
- Process: a business process uses “two or more applications to complete its task”. Something has to happen over there.
- Data: “synchronize data that resides in two or more systems”. Something has to be the same over there.
- Virtual: a user can “view, search, and modify data that’s stored in an external system”. The data stays over there.
Does anyone wait? The question from module 1. Salesforce’s words: synchronous is “blocking and real time”, a request and a response; asynchronous is “nonblocking, queue, or message-based”, and “the caller… continues without waiting for a response.”
Salesforce’s Selection Tables
Section titled “Salesforce’s Selection Tables”Answer the three, find your row, and the table names the pattern to consider.
Salesforce’s selection tables.
Read it the way you’d read it on the exam, and notice three things.
Coming in, it’s nearly always Remote Call-In. Three of the four rows into Salesforce are Remote Call-In. What changes is the mechanism: module 3 has the list. Only one row is different: data, coming in, where nobody waits. That’s Batch Data Synchronization.
Request and Reply answers two rows going out, process and data. If Salesforce waits, for something to happen or for data to come back, it’s request and reply.
The tables don’t show everything. Batch Data Synchronization is in the inbound table only, but Salesforce’s own definition says “Updates in either direction are done in a batch manner,” and its solutions include Salesforce as the source. So if the data goes out in bulk, every night, it’s still batch. The tables are a starting point. The pattern’s own page is the answer.
Test knowledge. Know Salesforce’s pattern selection tables: the three types (process, data, virtual), the two timings (synchronous, the caller waits; asynchronous, it doesn’t), and the key pattern for each row, from Salesforce to another system and from another system to Salesforce. Know that Remote Call-In covers every inbound row except data, asynchronous, which is Batch Data Synchronization.
Three Arrows, Three Patterns
Section titled “Three Arrows, Three Patterns”Here are three arrows from Steve Trucking, through the three questions.
Three arrows, three patterns.
The day-before message. Salesforce starts it, and something has to happen over there: a text goes to the recipient. Does Salesforce wait for the text to be delivered? No. The provider accepts the request and sends it when it sends it. Out, process, asynchronous: Fire and Forget. You get a receipt, not the outcome.
FleetLink’s latest position. FleetLink starts it, and the data has to be the same in Salesforce: where the truck is now. Each call waits for Salesforce’s answer. In, data, synchronous: Remote Call-In. Now remember chapter 6’s what-if: about 200,000 readings a day. One call per reading spends two thirds of the org’s daily allocation; one call every five minutes with every truck’s latest position is about 144 calls a day. Same pattern, same requirement, very different design. The pattern doesn’t finish the job. The numbers do.
Say Finance sends each partner’s new rates every night. Finance starts it, it’s data, and nobody is waiting: it runs at night, in bulk. In, data, asynchronous: Batch Data Synchronization.
When It’s Not Obvious
Section titled “When It’s Not Obvious”Most of the hard choices are between two patterns that are both reasonable. Each one comes down to a question you’ve already met.
- Request and Reply, or Fire and Forget? Does anyone wait for the outcome? If a person or a process can’t go on without it, it’s request and reply, however fast the event is (module 1).
- Remote Call-In, or Batch Data Synchronization? How many, and how soon? Do your number of zeros. A few records that must arrive in minutes: call in. A whole day of changes that must be right by morning: batch.
- Request and Reply, or Data Virtualization? Both are synchronous and both go out. Do you need to keep the data? Copy it, or see it (module 3).
- Point to point, or publish and subscribe? How many systems care, and will more come? (module 4).
Batch Is Your Backup Plan
Section titled “Batch Is Your Backup Plan”There’s one more choice, and it’s not either-or. Batch has a very specific mechanism. And a lot of times, when you combine events, you layer them with batch. For any kind of movement, batch is your backup plan.
Here’s why. Events give you the near real time. But remember module 4: a subscriber that’s away longer than the event is kept misses it, and nothing tells the publisher. Batch gets you a whole date range and puts you back in alignment.
Frame 1 of 2: events alone. Away too long, and the changes are gone.
Frame 2 of 2: events, and a batch underneath.
At Steve Trucking, the status history in Snowflake gets each status change as it happens, through events. And every night, the integration layer reads the day’s changes by date and fills any gap. On a good day, the batch finds nothing to fix. On a bad day, it’s the reason nobody noticed. In many cases, I’ll be layering a batch in there.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- For every arrow: which way, what kind, and whether anyone waits, and so the pattern Salesforce’s tables point to.
- Where the tables stop: batch going out, and the arrows that need the pattern’s own page.
- For every close call: the question that decides it, and the answer, written down.
- For every flow built on events: the batch underneath, how often it runs, and how far back it reads.
Beyond the exam: what AI changes. Ask an AI to pick a pattern and it will, every time, with confidence. Give it the three answers, which way, what kind, does anyone wait, plus the numbers, and it will usually pick the same one the table does. Give it only “integrate Salesforce with FleetLink”, and it’s guessing. The questions are still yours to answer.
Explore
Section titled “Explore”- Salesforce Architects, Integration Patterns (opens in a new tab): the Pattern Selection Guide, its two tables, and each pattern’s solution table, checked 2026-11-01.