Where the Conductor Lives

Module 6 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: The Saga and the Undo Step · Next: Long Waits and People

The question this module answers: When a process across systems needs a conductor, where should it run: in Salesforce, in the middleware, or somewhere built just for that?

A Conductor Needs a Home

Modules 4 and 5 made the case for a conductor: one place that knows the steps, keeps the state, and runs the undo steps when something fails. Enterprise Integration Patterns calls it a process manager: “a central processing unit… to maintain the state of the sequence and determine the next processing step based on intermediate results.”

That central unit has to live somewhere. There are three homes worth knowing, and each one is good at different work: inside Salesforce, in the middleware, or in a workflow engine built for long-running processes.

Click to enlarge

Three homes for the conductor.

Inside Salesforce

When most of the steps happen in Salesforce, and the people doing them work in Salesforce, the conductor can live there too. Salesforce gives you three ways to build it.

Flow Orchestration. Salesforce describes orchestrations as “multi-step processes that interact with multiple users and systems.” Each is “a sequence of stages, each comprised of one or more steps,” and “A stage can contain background, interactive, and MuleSoft steps.” The interactive steps are the point: a person gets an assigned task, and “the designated user receives an email with a link to their assigned action.” It’s the natural home for a process that waits on people, which is module 7. And it’s more available than it used to be: “Orchestration is a standard Flow type as of February 18, 2026,” included “for all Salesforce customers (subject to edition limits for Flow).” What that means for your contract is a question for your account executive, as Salesforce itself says.

Apex, with a Transaction Finalizer. For a conductor in code, a Queueable job runs each step, and a Transaction Finalizer runs after it, whether it succeeded or failed. Salesforce’s guide: finalizers “attach actions, using the System.Finalizer interface, to asynchronous Apex jobs that use the Queueable framework,” and “A Queueable job that failed due to an unhandled exception can be successively re-enqueued five times by a transaction finalizer.” So the finalizer is where you decide: try again, move on, or start the undo steps.

Chains of platform events. One step publishes an event, the next step’s subscriber hears it and does its part. That’s choreography inside the org (module 4, and chapter 11 module 6). It works, but remember module 4’s warning: nobody knows the whole process unless you build a record that does.

What all three share: they run on Salesforce’s limits, and every callout they make counts against them (chapter 9 module 5). A conductor that spends most of its time calling other systems is spending Salesforce’s resources on work that’s mostly elsewhere.

In the Middleware

When most of the steps are in other systems, the middleware is usually the better home. In my classes I list what a middleware does for you: the routing of traffic, coordination and orchestration, central security. Chapter 5 drew it as the hub (chapter 5 module 5), and Enterprise Integration Patterns says the same about the process manager: “Using a Process Manager results in a so-called hub-and-spoke pattern of message flow.”

The middleware is built for this work. It holds the credentials for every system, so Salesforce doesn’t have to. It has retries, queues and circuit breakers built in (chapter 14). And Salesforce makes one call and gets one answer, module 1’s “to Salesforce it appears to be one transaction.”

Integration platforms that do this include MuleSoft, which is Salesforce’s own, and the others chapter 5 named. Whatever the product, the question I always ask is the same: can your middleware handle your traffic volumes, and what happens if your middleware goes down? A conductor that’s down stops every process it conducts.

In a Workflow Engine

Some processes run for days, weeks or months: an onboarding, a claim, a contract that waits for three signatures. Some cross so many systems that no one system is the natural home. For those, there’s a third kind of home: a workflow engine, built to keep a process’s state and progress through anything.

A few, in their own words:

• AWS Step Functions: “you can create workflows, also called State machines, to build distributed applications, automate processes, orchestrate microservices.”
• Azure Durable Functions: “an extension of Azure Functions that lets you build stateful workflows in a serverless environment.”
• Camunda: “orchestrate and automate business processes, including people, systems, devices, and AI agents,” modelled in BPMN, the standard notation for business processes.
• Temporal: “a platform that guarantees the Durable Execution of your application code,” which it defines as the ability of a workflow “to maintain its state and progress even in the face of failures, crashes, or server outages.”

That last phrase is the reason to use one. A workflow engine’s whole job is to remember where every process is, even if the servers running it restart halfway through a step. Salesforce then becomes one of the systems the engine calls, or one that starts the process.

Choosing Where It Lives

Click to enlarge

Put the conductor where most of the steps are.

The short version: put the conductor where most of the steps are, and where the state can survive. A process that’s mostly Salesforce records and Salesforce users belongs in Salesforce. A process that’s mostly calls to the ERP, inventory and a payment provider belongs in the middleware. A process that runs for weeks across many systems belongs in something built to keep its place for weeks.

And whichever home you choose, it inherits everything from chapter 14: it logs every step with one ID, it retries in one layer only, and it has an owner and a runbook.

Test knowledge. Know where a multi-step process across systems can be coordinated: in Salesforce (Flow Orchestration for multi-step, multi-user processes; asynchronous Apex), or in middleware, which can also handle routing, transformation, security and error handling across systems. Know that coordinating several external systems from Salesforce spends Salesforce’s own limits on each call.

Beyond the exam: what AI changes. Agents are a new candidate for the conductor’s chair: give one a goal and some tools, and it decides the steps as it goes. That’s powerful, and it’s also a conductor that may choose different steps tomorrow. For a process where the steps and the undo steps must be the same every time, a designed conductor is still the safer home, and the agent can be one of the steps it calls. Module 8 comes back to this.

What an Architect Decides Here

• Where each process’s conductor lives, from where most of its steps are, who takes part and how long it runs.
• Inside Salesforce, which tool: Flow Orchestration, Apex with a finalizer, or a chain of events with a record that follows it.
• In the middleware, what happens when it’s down, and whether it can carry the volume.
• For long processes, whether a workflow engine is worth adding, and how Salesforce starts it and is called by it.
• The state: where it’s kept, so “where is this process?” has one answer.

Explore

• Salesforce Help, Automate Complex Processes with Orchestrations (opens in a new tab) (checked 2026-11-07).
• Salesforce Admins, Flow Orchestration Is Now a Standard Flow Type (opens in a new tab) (February 2026, checked 2026-11-07).
• Apex Developer Guide, Transaction Finalizers (opens in a new tab) (checked 2026-11-07).
• Enterprise Integration Patterns, Process Manager (opens in a new tab) (checked 2026-11-07).
• AWS Step Functions (opens in a new tab), Azure Durable Functions (opens in a new tab), Camunda 8 (opens in a new tab) and Temporal (opens in a new tab): each in its own documentation (checked 2026-11-07).