One Call, Many Steps

Module 1 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous chapter: Reliability, Recovery, and Observability · Next: The User Waits

The question this module answers: When one request from Salesforce sets off several steps in other systems, what does the caller actually know, and what should it be told?

Check the Balance, Then Submit

Here’s a use case I’ve seen many times. Salesforce wants to submit an order to the ERP. But first it should check the customer’s balance in the accounting system, and not submit if they’re overdrawn.

You have two choices. Salesforce can call accounting, come all the way back, decide, and then call the ERP: two round trips, coordinated by Salesforce, the client. Or Salesforce can make one call to the middleware, and the middleware checks the balance, submits the order, and updates inventory. To Salesforce, it appears to be one transaction.

Chapter 5 drew both, in two frames, when it showed what a hub in the middle can do (chapter 5 module 5). This chapter is about what happens after you’ve drawn that: the work of coordinating several steps across systems. That’s orchestration. And it starts with three words in that sentence: appears to be.

It Only Looks Like One Transaction

Inside Salesforce, a transaction is a real thing. Everything in it commits together, or nothing does. Salesforce’s own patterns guide counts on that for a call where a person waits: “Changes aren’t committed to Salesforce until the caller receives a successful response.”

The middleware’s three steps aren’t like that. Accounting answers. The ERP accepts the order, and that order is now real in the ERP, whatever happens next. Then inventory is updated, or isn’t. Each system commits its own step, on its own, as it happens. There’s no single moment when all three commit together, and no single button that takes all three back. Module 3 takes that apart.

So “one transaction, to the caller” means something narrower than it sounds. It means one request and one answer. Behind them are several steps, each of which can succeed or fail by itself. One call simplifies Salesforce’s side of the conversation. It doesn’t make the work underneath any simpler. It moves that work to somewhere else.

What If the Accounting Is Up and the ERP Is Down?

That’s the question I ask a class as soon as we draw the orchestration. Whoever coordinates the steps, Salesforce or the middleware, has to handle the logic. What if accounting is down but the ERP is up? What if accounting is up and the ERP is down? And what do you tell the users?

When you get into orchestration, you need to think about the times it works, and just as hard about the times it doesn’t. With two systems, there are four ways it can go:

Click to enlarge

Four ways it can go, and an answer for each.

Look at the square where accounting is down and the ERP is up. Nobody can check the balance. Do you stop every order until accounting is back? Or do you accept orders and check the balance afterwards, accepting a small risk? That’s not a technical question. It’s a business one, and the business has to answer it before it’s built, because the code will do something, and you want it to be what they chose.

And two systems is the easy version. Add inventory, and there are eight combinations. Add a fourth system, sixteen. So you don’t write a rule for every combination. You decide, for each step, what happens if that step fails: stop, wait, carry on without it, or undo what came before. Module 5 turns that into a pattern.

The Worst Answer: No Answer

There’s a fifth way it can go, and it’s the hardest one. Salesforce calls the middleware, and the call times out. Did the order go through?

Salesforce doesn’t know. Maybe accounting was slow and nothing happened. Maybe the ERP accepted the order and the answer was lost on the way back. If Salesforce simply sends the order again, it may create a second one.

The Data Architect course calls this the unknown outcome: failure and uncertainty are different things, and the answer is to check before you retry, by the order’s own key (Safe to Retry). For an orchestrated call, that means the middleware needs a way to answer “what happened to order 1042?” separately from “place order 1042”.

An Answer That Says Which

So here’s the design point I want you to take from this module. If one call stands for several steps, the answer can’t just be “success” or “failure”. It has to say which steps happened.

For the balance-and-order call, the caller might get back any of these:

Click to enlarge

Five answers, not two.

The web already has a word for the middle answer. HTTP’s 202 Accepted “indicates that the request has been accepted for processing, but the processing has not been completed”, and the standard adds, honestly, “The 202 response is intentionally noncommittal.” When the middleware has your order but can’t promise it’s placed yet, that’s what it should say, and Salesforce should show the user a pending order, not a finished one.

That list of answers belongs in the contract between Salesforce and the middleware (chapter 3’s contract, one more time). The middleware team builds them, the Salesforce team shows them to users, and both agree on what each one means before either starts.

Who Holds the Plan

The two choices from the start of this module are really a question of who holds the plan: who knows the steps, their order, and what to do when each one fails.

When Salesforce holds it, it calls each system itself. Salesforce knows every step, needs a connection and credentials for each system, and its own limits apply: callouts per transaction, time, the user waiting. Fine for two quick calls. Hard for five.

When the middleware holds it, Salesforce makes one call and gets one answer. The steps, the connections and the failure handling live in one place built for it, and every caller gets the same behavior. But that place now has to be right, and it has to be up. If the middleware goes down, every orchestration it runs goes down with it.

Neither is always right. Module 6 looks at all the places the plan can live, Salesforce, middleware, or a workflow engine, and how to choose.

Beyond the exam: what AI changes. Ask an AI assistant to “check the balance, then submit the order”, and it will happily write the two calls in a row, and handle the case where both work. Ask it about the other three squares and the missing answer, and it will handle those too, if you ask. It won’t decide what the business wants when accounting is down. Write that decision down first, then hand it over.

What an Architect Decides Here

• Who holds the plan for each multi-step call: Salesforce, or the middleware.
• For each step, what happens if that step fails: stop, wait, carry on without it, or undo.
• The business rule for each failure the code can’t decide alone, agreed before it’s built.
• The answers the call can return, written into the contract: done, refused, pending, couldn’t check, unknown.
• How the caller asks what happened when no answer came back, by the request’s own key.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): Request and Reply, and who handles the error (checked 2026-11-07).
• IETF, RFC 9110, HTTP Semantics (opens in a new tab): 202 Accepted (checked 2026-11-07).
• Point to Point, or Hub and Spoke: chapter 5, the two frames of this example.
• Safe to Retry: the Data Architect course, the unknown outcome.