Salesforce Flow Orchestration
A Salesforce Flow Orchestration is an automation that strings several flows together into one multi-step, multi-user process.
Definition
A Salesforce Flow Orchestration is an automation that strings several flows together into one multi-step, multi-user process. It coordinates work that runs over hours or days, pausing between steps to wait for a person to finish a task, for an approval, or for a background flow to do its job. You build it in Flow Builder by choosing the Orchestration flow type.
A regular flow runs start to finish in one go. An orchestration is different because it can stop, hand work to a named user or queue, and pick back up when that work is done. It groups the flows it runs into stages, so a long process like onboarding or a deal review has clear phases you can watch from start to finish. Since the Spring 2026 release wave, Flow Orchestration is a standard Flow type that no longer needs a separate add-on license.
How an orchestration coordinates people and flows
What an orchestration is built from
An orchestration has three building blocks: the orchestration itself, stages, and steps. The orchestration is the container. It starts either when a record is created or updated (a record-triggered orchestration) or when something invokes it directly such as a button, the API, or Apex (an autolaunched orchestration). Inside the container you add stages. A stage is a phase of the process, like Triage, Review, or Close, and it groups the steps that belong to that phase. Stages run in order, and only one stage is in progress at a time. Each stage finishes when its completion conditions are met, then the next stage begins. Steps live inside stages and do the real work by running a flow. You can also add decision steps and evaluation flows that branch the path based on data. This layered shape is what lets you map a messy real-world process into something Salesforce can run and report on. The stage view gives admins and managers a plain picture of where any single run currently sits.
Interactive steps and background steps
Steps come in two kinds, and the difference is whether a human is involved. A background step runs an autolaunched flow with no user interaction. It is good for the silent work in a process: updating records, calling an external system, sending a notification, or scoring a lead. The orchestration runs it and moves on automatically. An interactive step runs a screen flow and needs a person to act. When an interactive step starts, the orchestration creates a work item and assigns it to a user, a group, or a queue. It then emails the assigned people a link to the record so they can pick the work up. The screen flow opens inside the Flow Orchestration Work Guide, a component you place on the record page, so the assignee does the task without leaving the record. The step does not complete until the person finishes the screen flow. This is the mechanism that lets a process pause for human judgment, then continue once the judgment is in.
Sequential versus parallel steps
Within a single stage you decide how the steps relate to each other. Sequential steps run one after another, so step two only begins once step one is done. Use this when each task depends on the result of the one before it. Parallel steps run at the same time inside the same stage. Use this when several tasks can happen independently and you want to shorten the total elapsed time. A classic example is a support case that spikes in severity. Engineering can investigate the root cause while a customer success rep reaches out to the account, both at once, instead of one waiting on the other. Parallel work is where orchestration earns its keep, because a chain of separate flows cannot fan work out to two teams and then regroup. The stage holds the parallel steps together and does not advance until its completion conditions are satisfied. Mixing sequential and parallel steps across stages is how you model real handoffs, where some work is strictly ordered and some is not.
Passing data and making decisions
An orchestration is more than a list of flows. It moves data between them and branches on that data. When you add a step, you map values into the flow it runs and capture the flow output back into orchestration variables. Those variables are then available to later steps, so a value collected in a screen flow during stage one can drive a background flow in stage two. Decision steps and stage exit conditions read these variables to choose a path. A loan orchestration might branch to an escalation stage only when the requested amount crosses a threshold, and otherwise route straight to approval. Evaluation flows give you custom logic when simple field checks are not enough. This data flow is what keeps the orchestration coherent across time. The record that triggered it stays the anchor, and each step reads and writes context as the process advances. Planning your variables up front, before you wire the steps, saves a lot of rework later, because changing a flow input map after the fact can ripple through every step that depends on it.
Running and monitoring an orchestration
Once active, an orchestration spins up a run-time instance for each record or trigger. Salesforce tracks each instance so you can see exactly where it is. The Orchestration Runs and Orchestration Work Items pages let admins watch active runs, see which stage is in progress, and find which work items are still open and who they belong to. Each interactive step that fires is recorded as a Flow Orchestration Work Item, an object available since API version 54.0, with the assignee and status attached. If a run stalls because an assignee never acts, this is where you spot it. You can reassign a work item to move things along. For end users, the experience is simpler. They get an email, click through to the record, and complete their screen flow in the Work Guide. They never need to understand the stages behind the scenes. This split, rich monitoring for admins and a clean task list for users, is deliberate. It keeps a complex multi-team process governable without forcing every participant to learn the whole map.
When to reach for orchestration
Not every automation needs an orchestration, and reaching for one too early adds overhead. A single screen flow or a record-triggered flow handles most day-to-day automation just fine. Orchestration fits when a process is genuinely multi-step, multi-user, and long-running, with pauses for people in between. Employee onboarding is a textbook case: IT provisions accounts, a manager assigns a buddy, facilities sets up a desk, and HR confirms paperwork, each a separate task owned by a separate team. Deal desk reviews, mortgage processing, and multi-stage case handling fit the same pattern. The tell is that the work crosses several people and cannot finish in one transaction or one sitting. If your process is just a few automated field updates with no human handoff, a plain flow is simpler and cheaper to maintain. If it sprawls across teams and days with approvals and reviews threaded through it, an orchestration gives you the coordination and the visibility a chain of disconnected flows cannot. Match the tool to the shape of the work.
How to build a Flow Orchestration
You build an orchestration in Flow Builder, the same place you build regular flows. Plan the stages and the underlying flows first, then assemble them. Here is the high-level path.
- Create the flows you will orchestrate
Build the screen flows and autolaunched flows the orchestration will run, and activate them. The orchestration calls these as its interactive and background steps, so they need to exist first.
- Start a new Orchestration in Flow Builder
In Setup, open Flow and click New Flow. Choose the Orchestration flow type, then pick a record-triggered start (fires on create or update) or an autolaunched start (invoked by a button, the API, or Apex).
- Add stages and steps
Add stages for each phase of your process. Inside each stage, add steps that run your flows. Set each step as interactive (runs a screen flow, needs a person) or background (runs an autolaunched flow, no person).
- Assign work and set conditions
For interactive steps, set the assignee to a user, group, or queue. Map inputs into each flow and capture outputs. Add decision steps or stage completion conditions to control the path, then activate the orchestration.
Record-triggered launches automatically on a record create or update. Autolaunched is invoked on demand by a button, Apex, or the API.
Runs a screen flow and creates a work item assigned to a user, group, or queue, surfaced in the Flow Orchestration Work Guide.
Runs an autolaunched flow with no user interaction, used for record updates, callouts, and other silent work.
Defines when a stage is done so the orchestration can advance to the next stage in sequence.
- Stages always run one at a time and in order; only steps inside a stage can run in parallel, not the stages themselves.
- An interactive step will not complete until the assigned person finishes the screen flow, so a stalled run usually means an open, unworked work item.
- Place the Flow Orchestration Work Guide component on the relevant record page, or assignees will get the email but have nowhere to do the task.
- Plan your flow input and output mappings before wiring steps; changing them later can break every downstream step that reads those values.
Trust & references
Cross-checked against the following references.
- Orchestration StepsSalesforce
- Flow Orchestration Interactive StepsSalesforce
Straight from the source - Salesforce's reference material on Salesforce Flow Orchestration.
- Flow Orchestration Background StepsSalesforce
- FlowOrchestrationWorkItem Object ReferenceSalesforce
Hands-on resources to go deeper on Salesforce Flow Orchestration.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Flow Orchestration?
Q2. How does it differ from standard flows?
Q3. Does it require a special license?
Discussion
Loading discussion…