Listening for the Shape of the Integration

Module 2 of 6 in the chapter Understanding Integration Requirements, chapter 6 of the Integration Architect course. Each module stands on its own. Previous: Functional and Non-Functional Requirements · Next: Steve’s Number of Zeros

The question this module answers: When the business describes what it needs, what should you be listening for before you think about a tool?

The business won’t describe an integration in our words. They’ll say “when the opportunity closes”, or “when the truck delivers”, or “every night, from the warehouse”. Inside each of those sentences is the shape of an integration, and you need to be listening for it. Get the shape right and the pattern almost picks itself. Get it wrong and the best tool in the world won’t help.

There are four things I listen for: the action, the source and the target, the timing, and the volume. The volume is the next module. This one is the other three.

Listen for the Shape

The direction of action. Who’s initiating the action? An opportunity closes in Salesforce. A truck delivers, and a crew taps a mobile device. A nightly job pulls from a data warehouse, or pushes to one. Something happens, somewhere, and someone or something starts it.

And the direction of action can be different from the data flow. An action can push data out, or it can query, or it can pull. A user who opens a page starts the action, but the data comes back to them. That’s the same distinction chapter 1 drew for the arrow, who starts the call and which way the data moves, heard in the business’s own words.

The source and the target. Where does the data come from, and where does it go? Who’s the source? Who’s the target? Sometimes there’s more than one target, and sometimes the target sends something back.

The timing. How soon does it have to happen? This one changes the design more than any other, so it gets its own section below.

Here are three sentences a business might say, and what each one tells you.

Click to enlarge

What you hear, and what it tells you.

The first two are Steve Trucking. The third is a classic: check the customer’s balance before submitting the order. Notice the word before. It’s the one to watch for.

How Soon

The timing makes a significant difference. There’s a big difference between under a second and one to five minutes.

Real time is synchronous: the caller sends the request and waits for the answer, in the same call. The user is sitting there. That means the other system has to answer fast, every time, and when it doesn’t, you need a lot of error handling: what does the user see, do you retry, what’s been saved? Watch for those synchronous requirements. They’re the hardest to fulfil.

Near real time is my name for the space in between: as low as under a second, to seconds, to maybe a minute or two or five. Something happens, it’s sent, and nobody waits for the answer. That’s a lot cheaper and easier to maintain than real time. And it’s usually what the business means when it says “real time”. The partner should know when the delivery is done; nobody’s sitting at a screen waiting for the partner to reply.

Batch is more old school, and still the right answer for a lot of things. Collect the changes, then send them together. Is that batch hourly, daily or weekly? The data can be hours old, and for many uses that’s fine.

Click to enlarge

Real time, near real time, batch.

Salesforce’s own integration patterns use two words for this: synchronous, “Blocking and real time requests are request/response operations,” and asynchronous, “Nonblocking, queue, or message-based requests” (Integration Patterns (opens in a new tab), Salesforce Architects, checked 2026-11-01). Near real time and batch are both asynchronous; they differ in how long the data waits.

So when the business says “real time”, ask one question: does someone wait for the answer? If yes, it’s synchronous, and you design for the hardest case. If no, it’s near real time, and you just saved them a lot of money.

Consider All the Flows

A requirement is rarely one arrow. Most times you’re going to have multiple flows of integration for one business need. And some of them nobody mentions.

Take batch data synchronization. If you’re going to keep two systems in step every night, how are you seeding the data in the first place? You need a big initial data load before the first nightly run, and that’s its own flow, with its own volume and its own timing. Delivery status out to the partner probably needs a way to send the history again when the partner’s system is restored. A synchronous check needs to know what to do when the other side doesn’t answer.

And plan for tomorrow. Two workflows might turn into five.

From Shape to Pattern

Once you have the shape, you’re most of the way to a pattern. Salesforce’s integration patterns are named for exactly these shapes: Salesforce calls another system and waits for the answer (Request and Reply), or calls and doesn’t wait (Fire and Forget); data kept in step in batches (Batch Data Synchronization); another system calling in to create, read, update or delete (Remote Call-In); the screen updating when the data changes (UI Update Based on Data Changes); and reading data where it lives without copying it (Data Virtualization). Chapter 7 takes each one apart.

The order matters: shape first, then pattern, then the mechanism. If someone starts the conversation with a tool (“we’ll use platform events”), bring it back to the shape: who starts it, from where to where, and does anyone wait?

What an Architect Decides Here

• For every requirement: who starts the action, and whether the data flows the same way.
• The source and the target, and every target, including the ones that send something back.
• The timing: real time, near real time or batch, and, for anything called “real time”, whether someone really waits for the answer.
• Every flow behind the need, including the initial load and the ones nobody mentioned.
• Which pattern the shape points to, before anyone picks a tool.

Beyond the exam: what AI changes. AI agents blur the timing. A person asking an agent a question is waiting, so whatever the agent calls to answer it is effectively real time, even if the business never said so. And an agent can start actions nobody planned, at any hour. So for every system an agent can call, ask the same three questions: who starts it, from where to where, and does anyone wait? The answer is often “yes, a person, right now”, and that’s the hardest kind.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): the six patterns, and timing as synchronous or asynchronous, checked 2026-11-01.
• Every Arrow Is a Decision: who starts the call, and which way the data moves.