Integration Orchestration

Chapter 15 of Integration Architect, Part 2: Designing Integrations That Work (Design). Previous: Reliability, Recovery, and Observability · Next: Choosing the Right Integration Design.

Salesforce wants to submit an order to the ERP, but it should check the customer’s balance first, and update inventory after. One piece of work, three systems. Who coordinates the steps? What happens when the second one fails after the first one succeeded? And what do you tell the person waiting on the screen?

That’s orchestration: coordinating work that spans systems. It’s where the ideas of Part 2 come together. The calls in and out, the events, the identities and the failure handling all meet in one process that has to work end to end, or come back cleanly when it doesn’t.

The running example is my own: the balance, the order and the inventory. Steve Trucking appears where it fits, its status events and a paid redelivery among them.

The ideas in this chapter

It only looks like one transaction. One call to the middleware means one request and one answer, with several steps behind it, each committed on its own. So the answer has to say which steps happened: done, refused, pending, couldn’t check, or unknown.
If a person waits, build the screen that waits. The standard Save can’t pause for another system. A screen flow or a Lightning web component checks, then shows, then saves, and every answer, including no answer, has something on the screen.
There’s no rollback across systems. Each system commits its own step. The work sits in between, so make that visible: a status that acts as a lock, with a time limit and an owner.
A conductor, or systems that react. Orchestration knows where the work is and can be the single point of failure; choreography keeps systems apart and nobody knows the whole process. Choose per piece of work, not per company.
Every step has an undo. A saga undoes what already happened with new steps, in reverse; steps that can’t be undone go last, after the point of no return; and the undo must be safe to repeat, because it can fail too.
Put the conductor where most of the steps are. Inside Salesforce, in the middleware, or in a workflow engine that keeps a process’s state through failures.
Every wait has two ways out. Save the state, never hold a call open, and give every wait a deadline as well as the answer.
Agents are conductors too. The same rules apply, and Salesforce’s own guidance asks for them: named undo steps, every write safe to repeat, the same key on a retry.

The path through this chapter

Eight modules, each standing on its own.

One Call, Many Steps. Check the balance, then submit; it only looks like one transaction; what if the accounting is up and the ERP is down; the worst answer, no answer; an answer that says which; who holds the plan.
The User Waits. Why the standard Save can’t do it; a screen flow or a Lightning web component; where the transaction ends; the screen itself; when it’s too slow for a screen.
There’s No Rollback Across Systems. Undo inside Salesforce, none across; the state in between; the order’s states; eventually, with an owner.
Orchestration or Choreography. Two ways to coordinate; what each gives and costs; Steve Trucking uses both; choosing.
The Saga and the Undo Step. Every step has an undo; some can’t be undone; the point of no return; the undo can fail too; who runs the saga; a paid redelivery.
Where the Conductor Lives. Inside Salesforce; in the middleware; in a workflow engine; choosing.
Long Waits and People. A wait is saved state; every wait needs a deadline; the step that never answers; while you wait, the world changes.
Orchestrating Agents. A new kind of conductor; the same rules in Salesforce’s words; the agent as the conductor, or as a step.

Chapter 16 brings Part 2 together: choosing the right design for each arrow, and Checkpoint 2, Steve Trucking end to end.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

For every process that spans systems: who holds the plan, and the answers its caller can get back.
Whether a person waits, and if so, the screen: the order of the steps, the wait, every answer.
The in-between states, what each one locks, how long it may last, and who owns it.
Orchestration or choreography, per piece of work.
For every step: its undo, where the point of no return falls, and what happens when an undo fails.
Where the conductor lives: Salesforce, the middleware, or a workflow engine.
For every wait: its deadline, and what happens on it.
For agents: conductor or step, and an undo and a key for every action they can call.

Beyond the exam: an AI agent will happily chain five calls across three systems, and handle the case where they all work. What it won’t decide is what the business wants when the third one fails, which step is the point of no return, or how long a wait may last. Those decisions are this chapter, and they matter more, not less, when the conductor is an agent.

Explore

microservices.io, Pattern: Saga (opens in a new tab): the saga and its compensating transactions.
Microsoft Learn, Azure Architecture Center, Saga design pattern (opens in a new tab) and Choreography pattern (opens in a new tab).
Salesforce Architects, Agentic Integration Patterns (opens in a new tab): the same rules, for agents.

Next: Choosing the Right Integration Design