Flow Orchestration co-ordinates work across several people over hours or days. It groups flows into stages and steps, hands interactive steps to users or queues as work items, and runs each step in its own transaction with its own governor limits. Most teams do not need it. If your process is one person filling in one wizard in one sitting, a screen flow is the correct tool and orchestration is overhead.
The structure
An orchestration is a flow type of its own, either autolaunched or record-triggered. Inside it you build stages, and inside each stage you build steps.
Stages run in sequence. Each has entry conditions and exit conditions, so a stage begins when its criteria are met and completes when all its steps are done.
Steps sit inside a stage and can run in parallel with each other. There are two kinds. A background step runs an autolaunched flow with no human involved. An interactive step runs a screen flow and creates a work item assigned to a user, a queue, or a resource defined by a formula.
Users pick up interactive steps through the Orchestration Work Guide component, added to a record page or a home page. That component is what makes the whole thing usable, and an orchestration without it deployed is an orchestration nobody can complete.
The genuine advantages
Limits reset per step. Each step runs in its own transaction. A long process that would blow through 100 SOQL queries as a single flow can be split across steps and stop being a limits problem. This is the strongest technical argument for orchestration and it is not available any other way short of chaining async paths.
Assignment is built in. Work items go to a user or a queue, appear in a list, and can be reassigned. Building the same thing with Tasks and a screen flow means building the routing, the visibility, and the completion tracking yourself.
State is visible. An orchestration run records which stage it is in and which steps are outstanding. When someone asks where a request has got to, there is an answer, which is not true of a process implemented as five unrelated record-triggered flows.
Where it does not earn its place
A single-user wizard is a screen flow. Adding orchestration around it gives you a work item to click before you can start, and nothing else.
A simple approval is an Approval Process. Approvals already have delegation, recall, history, and email responses, all of which you would be rebuilding. Orchestration is for processes where the work is doing something, not just deciding something.
The honest assessment
The builder is less pleasant than Flow Builder. You are assembling a shell around flows you still have to build and maintain separately, so the number of pieces of metadata goes up rather than down. Debugging is thinner: you can see where a run is, but tracing why a step did what it did means opening the underlying flow and debugging that.
Orchestrations are designed to move forwards. Building a “send it back to the requester” path means designing that as its own stage rather than jumping backwards, which changes how you model the process.
And it is licensed separately from the rest of Flow. Check what your org is actually entitled to before you design a quarter’s work around it, because discovering the commercial position after the design is finished is a bad afternoon.
How to decide
Ask three questions. Does the process involve more than one person? Does it span more than one sitting? Does anyone ever need to ask where it has got to? Three yeses and orchestration is worth evaluating. Two or fewer and you are almost certainly better served by a screen flow, a record-triggered flow, and a well-named status field.
Frequently asked
Can a step call any flow? Background steps call autolaunched flows. Interactive steps call screen flows. The step passes values in and out through the flow’s input and output variables, so those need the availability checkboxes ticked, same as a subflow.
What happens if a step’s flow fails? The run stops at that step and reports the error. Build fault paths inside the underlying flows so the orchestration is not the only place errors surface.
Can I reassign a work item? Yes, work items support reassignment, which is one of the practical reasons to choose orchestration over a home-grown Task-based process.
