Flow Orchestration used to cost extra. Now it does not. Starting with Summer '26, Flow Orchestration runs are included in Enterprise, Performance, Unlimited, and Developer editions without usage-based limits. If you ruled it out before because of the pricing, that calculation is gone. Here is what Flow Orchestration actually does, and why it is worth a fresh look.
What Flow Orchestration actually is
A regular Flow handles a trigger and a sequence of automated steps. It runs, completes, and is done — typically in seconds, with no pause for a human to weigh in partway through.
Flow Orchestration is built for a different category of process: multi-step, multi-user business processes that require coordination across people, systems, and time. The work needs to pause, wait for a specific person to make a decision, branch based on that decision, and continue — all in a monitored, auditable way, potentially over hours, days, or weeks.
The distinction matters because many processes that orgs currently handle through a combination of email, manual task assignment, and someone remembering to follow up are exactly the kind of process Orchestration is built for. The reason most orgs have not built these in Salesforce is that Orchestration previously carried a usage-based cost that made it hard to justify for internal process automation rather than customer-facing workflows.
| Characteristic | Regular Flow | Flow Orchestration |
|---|---|---|
| Duration | Runs and completes in seconds. No pause for human input mid-process. | Can span hours, days, or weeks — pauses at human steps and resumes when action is taken. |
| Human involvement | Limited to triggering the flow or responding to a single approval step bolted on separately. | Built-in stages where specific people are assigned tasks, make decisions, and the process branches based on their input. |
| Visibility | No persistent status view. Once running, you cannot easily see "where" the flow currently is. | Defined stage model — anyone can see which stage a process instance is currently in and who owns it. |
| Multi-department coordination | Difficult — typically requires chaining multiple flows and manual handoffs between departments. | Native — parallel and sequential stages across different teams with a single coordinated process instance. |
| Best for | Record updates, notifications, single-step automations, data validation, immediate actions triggered by a record change. | Onboarding processes, approval chains, multi-department workflows — anything where "who does this next and when" is the core challenge. |
| Cost (Summer '26) | Included in all editions, as always. | Now free Included in Enterprise, Performance, Unlimited, and Developer editions — no usage-based limits. |
A simple orchestration, structurally
The shape of an orchestration is consistent regardless of the specific process: a system step does something automatically, a human step pauses and waits for a person to act, the orchestration branches based on what that person decided, and the process continues — potentially with more human steps, more branches, and a final system step that records the outcome.
What makes this different from a Flow with an Approval Process attached is the structure and visibility. Orchestration gives you a defined stage model — each stage has a clear owner, a clear set of possible outcomes, and a status that is visible to anyone checking on the process, not just the person whose turn it currently is. For processes spanning multiple departments, that visibility is often the missing piece.
Three workflows worth building now that it is free
New employee onboarding across IT, HR, and the hiring manager
Onboarding touches multiple departments with sequential and parallel dependencies: IT needs to provision accounts, HR needs to complete paperwork, the hiring manager needs to prepare the first-week schedule, and some of these steps depend on others completing first. An orchestration can sequence IT provisioning after HR confirms the start date, run HR paperwork and manager prep in parallel, and surface a single status view to whoever is coordinating the new hire's first day.
The alternative — the current state at most orgs — is a checklist in a shared document and a series of Slack messages asking whether each step is done yet. Orchestration replaces the asking with visibility.
Contract approval chain with parallel legal and finance review
A contract above a certain value needs review from legal and finance before it reaches an executive for final sign-off. Legal and finance review can happen in parallel — neither depends on the other — but the executive sign-off step depends on both being complete.
Orchestration models this directly: a parallel stage for legal and finance, a convergence point that waits for both to complete, then a sequential executive approval stage. The audit trail shows who reviewed what and when, without anyone needing to track it manually.
Deal desk workflow for non-standard pricing approvals
Non-standard pricing requests — discounts above a threshold, custom payment terms, non-standard contract clauses — typically need sign-off from sales leadership, finance, and sometimes RevOps, in an order that depends on the specific request. An orchestration can route the request to the right combination of approvers based on the deal characteristics, track where it currently sits, and notify the rep when a decision is made.
The business value here is speed: deal desk requests that currently take days because they sit in someone's inbox move faster when the orchestration actively routes and tracks them, and the rep has visibility into where the holdup is rather than just waiting.
How to get started in Summer '26
Flow Orchestration is found in Setup by searching for Flows, then selecting New Flow and choosing Orchestration as the flow type. The builder interface is similar to standard Flow Builder, with the addition of Stage elements that represent the human and system steps.
The one thing worth testing in sandbox first: notification behaviour for human steps. Orchestration stages notify the assigned user when it is their turn to act, and the default notification channel and timing may not match what your org expects.
Build a simple two-stage orchestration — one system step, one human approval step — and confirm the assigned user receives the notification through the channel your team actually monitors before building anything more complex.
The processes that always needed Orchestration did not stop needing it when the pricing made it hard to justify. They just kept running on email and shared spreadsheets. Summer '26 removes the reason not to fix that.
