Salesforce Flow Orchestration in 2026: the multi-step engine that just stopped costing extra

For years Flow Orchestration was the automation feature almost nobody used, and the reason was rarely the feature — it was the invoice. Orchestration ran on a paid, metered model: a small free allowance and then bundles of additional runs you had to buy from your account executive. So teams did what teams do when a capability has a meter on it — they avoided it, daisy-chaining a dozen record-triggered flows to fake a multi-step process rather than pay for the tool built to run one.

That reason is gone. In Spring ‘26, Salesforce made Flow Orchestration a standard feature — no add-on, no usage-based caps, included in Enterprise, Performance, Unlimited, Einstein 1, and Developer editions. The old per-run entitlement is retired; ordinary edition-based Flow limits apply instead. And the timing matters, because orchestration stopped costing extra at exactly the moment the thing it does — coordinate people, agents, and systems across a process that spans users, departments, and time — became the hard part of every Agentforce build. This post is what Flow Orchestration actually is under the hood, the new Flow-based approvals that modernize the old approval process, where Agentforce plugs in as a step, and the honest line where an orchestration is overkill and a single flow will do.

What an orchestration actually is: three nouns

A single flow runs in one transaction, start to finish, usually for one user. An orchestration is the layer above that: a durable, long-running process that spans transactions, users, and time, coordinating many flows. Its object model is three nouns.

• An orchestration is a sequence of stages.
• A stage groups related steps into a logical phase. Stages run sequentially — only one stage is In Progress at a time — and a stage completes when it meets its exit conditions or all its steps finish.
• A step runs a single flow. Within a stage, steps can run sequentially or concurrently (in parallel) — this is where orchestration earns its keep, because a plain flow can’t hand three parallel pieces of work to three different people and wait for all of them.

There are exactly two kinds of step, and the distinction is the whole design:

• Interactive steps assign an active screen flow to a user, group, or queue. They require a human. When the step runs, it creates a work item and notifies the assignee with a link to the record. This is how a person enters the process.
• Background steps run an autolaunched flow with no user interaction — a callout, a record update, a calculation, an agent action — behind the scenes.

Entry and exit are governed by evaluation flows: small autolaunched flows that return true/false to decide whether a step or stage can start, or whether it’s complete. A stage’s exit condition can be “when all steps complete” or “when this evaluation flow returns TRUE” — which is how you express “move on once the risk check passes, regardless of the other steps.”

A flow answers “what happens in this transaction.” An orchestration answers “what happens across this whole process, to whom, in what order, and what has to finish before the next thing starts.” If your process has more than one human and more than one moment, that second question is the one you actually have.

An orchestration comes in two flavors that mirror the flow types you already know. A Record-Triggered Orchestration starts automatically when a record is created or updated. An Autolaunched Orchestration (No Trigger) is started explicitly — from Apex, the REST API, a custom button, a URL, or another process. Launching an autolaunched orchestration from Apex uses the same Flow interview API as any autolaunched flow:

// Start an autolaunched orchestration and pass it the record it should run over.
Map<String, Object> inputs = new Map<String, Object>{
    'recordId' => opportunity.Id
};
Flow.Interview orchestration =
    Flow.Interview.createInterview('Deal_Desk_Orchestration', inputs);
orchestration.start();

Because an orchestration is durable, that single start() kicks off a process that might live for days — pausing on an interactive step while a manager approves something, resuming when they do — without you writing a single line of state management. That durability is the point. The state, the assignments, the “who still owes us a decision” all live in the platform, not in a scheduled job you have to babysit.

The step that runs an agent

The reason orchestration matters more in 2026 than it did in 2022 is that one of your background steps can now be an agent. Since Summer ‘25, you can drop an Agentforce agent into most flows through the Action element’s AI Agent Actions category — available in screen, autolaunched, and record-triggered flows — and the agent’s response comes back as a Structured Output, so named values pass cleanly into the flow’s variables instead of arriving as a blob of prose you have to parse.

Put those two facts together and orchestration becomes the thing people keep reaching for and not finding: a governed way to mix agent reasoning with human judgment and deterministic system steps, in one auditable process. A background step lets the agent draft, classify, summarize, or recommend. The next interactive step routes that output to a human when — and only when — the decision crosses a threshold that warrants a person. This is the human-in-the-loop pattern expressed as structure rather than hope: you don’t ask the agent to decide whether to escalate, you build a stage whose exit condition escalates for it.

A representative deal-desk orchestration reads like this:

• Stage 1 — Enrich (background). An autolaunched flow pulls the account’s history; an AI Agent Action drafts a risk summary and returns a riskScore and recommendedDiscount as structured values.
• Stage 2 — Review (interactive, conditional). An evaluation flow checks the score. If riskScore is low, the stage’s exit condition is met immediately and the process skips ahead. If it’s high, an interactive step assigns a screen flow to the deal-desk queue, and a human makes the call with the agent’s summary in front of them.
• Stage 3 — Execute (background). Once approved, autolaunched flows update the record, notify the rep, and fire the downstream integration.

Every one of those transitions is logged, reassignable, and monitorable — which is exactly what a bare agent action inside a single flow can’t give you. It’s worth being precise about the two senses of “orchestration” in play here, because Salesforce uses the word for both: multi-agent orchestration is agents delegating to agents at reasoning time; Flow Orchestration is a process engine that treats an agent as one participant among humans and systems. They compose — an agent inside an orchestration step can itself route to a team of agents — but they solve different problems, and conflating them is how designs go muddy.

Approvals, rebuilt in Flow

The other half of the 2026 orchestration story is approvals. The legacy Approval Process — the point-and-click wizard every admin has built a hundred times — is showing its age: rigid, hard to debug, no real parallelism, no clean recall. Salesforce’s answer is Approval Orchestration, built entirely inside Flow Builder using the same stages-and-steps model, and it comes in the same two shapes: Record-Triggered Approval Orchestration and Autolaunched Approval Orchestration (No Trigger).

What it buys you over the old process:

• Real parallel and dynamic approvers — multi-level, multi-approver chains where routing is driven by flow logic, not a static hierarchy field.
• Recall / withdraw, added in Summer ‘25 — a submitter can pull back a request in flight, which the legacy process never handled gracefully.
• Better error handling and debugging, with an enhanced Debug Mode and, since Winter ‘26, an Approval Designer permission that lets people build and change approvals without the sweeping Manage Flows permission.
• Cost that matches the old process: Flow-based approvals do not consume orchestration runs or automation credits. You get the modern engine at legacy-approval price — which is to say, free.

One important nuance, because practitioners keep asking and the internet keeps guessing: the legacy Approval Process has not been given an end-of-life date. Salesforce has stopped active development on it — no new features, the same posture it took toward Workflow Rules — but it is not deprecated and has no announced retirement. (The December 31, 2025 end-of-support milestone that everyone half-remembers applies to Workflow Rules and Process Builder, not to Approval Processes.) So the honest guidance is: build new approvals as Approval Orchestrations to get parallelism, recall, and debuggability; don’t feel forced into a panicked migration of every working legacy approval you own. New work forward, existing work left alone until it needs a change — the same measured stance we take toward Salesforce technical debt generally.

Summer ‘26 kept sharpening the approval surface: unanimous group-approval steps now issue every group member their own work item and close the step on the first rejection (note that these particular work items can’t be reassigned), and approvals became actionable in Slack — approve, reject, and comment without leaving the channel, with the history retained in Salesforce.

How the work reaches people, and how you watch it

Two operational surfaces decide whether an orchestration is usable in production rather than just buildable in a sandbox.

Getting work to humans. An interactive step creates a work item and emails the assignee, but the place they actually do the work is the Flow Orchestration Work Guide — a Lightning component an admin adds to the record page (and to Experience Cloud pages, so external users like partners or customers can complete steps too). Forget to place the Work Guide and your beautifully modeled orchestration assigns work nobody can find. When an assignee is out, an admin reassigns the work item to another user, group, or queue from the Orchestration Work Items list view.

Watching it run. Each running instance is an OrchestrationRun record. You monitor active orchestrations from the Orchestration Runs list view, where you can cancel or debug an In Progress run and see the path it took and the values of its variables. In Spring ‘26 orchestrations moved into the Automation Lightning app alongside flows, with clearer dependency visibility. One debugging caveat to set expectations: the orchestration debug view shows you the path and variables but not transaction boundaries or governor limits — for that, you debug the individual flows a step runs, not the orchestration wrapping them.

On limits: an orchestration’s steps are still flows, so standard Salesforce flow and governor limits apply to each one, and storage limits apply to the run records. Salesforce publishes a Flow Orchestration Limits and Considerations page; check it for the current caps on your edition rather than trusting a number from a blog — including this one — because those are exactly the figures that move between releases.

When Flow Orchestration is the wrong tool

The freeing of Flow Orchestration will produce a predictable failure mode: teams reaching for it because it’s there. Resist. Orchestration earns its complexity when a process is genuinely multi-user, multi-step, and multi-moment — sequence matters, more than one person touches it, and something has to finish before the next thing starts. If your automation is one user in one transaction, a single flow is simpler, cheaper to reason about, and easier to test. Wrapping a one-actor process in stages and steps buys you overhead and a second thing to version, with nothing in return.

This is the same tool-selection discipline as choosing between Flow, Apex, and Agentforce in the first place, one level up. Flow Orchestration is the conductor; it’s the right call precisely when you’d otherwise be hand-coordinating a daisy chain of flows, chasing approvals over email, and reconstructing “where is this request” from three record fields. It’s the wrong call when there’s nothing to conduct.

And a note on the shiniest new knob: Salesforce added an Agentforce side panel in Flow Builder (Beta) that edits screen and action elements from natural-language prompts, plus an “Ask Agentforce” (Beta) that diagnoses design-time and runtime flow issues and can auto-apply fixes — both requiring Data 360, Agentforce, and Einstein generative AI enabled. Useful for accelerating the build. But an orchestration is a governance artifact as much as an automation one, and a process you don’t fully understand is one you can’t safely change. Let the panel draft; you own the review.

What to actually do

Start by re-checking a decision you probably made years ago under the old pricing: is there a multi-step, multi-person process in your org that you wanted to orchestrate and instead built as a chain of triggered flows because orchestration cost extra? That’s now a free upgrade — rebuild it as a Record-Triggered Orchestration with proper stages, interactive steps for the humans, background steps for the systems, and evaluation flows for the transitions. Build new approvals as Approval Orchestrations for the parallelism, recall, and debugging, and leave working legacy approvals alone until they need a change. Where an agent belongs in the process, make it a background step returning structured output into a stage whose exit condition — not the agent’s own judgment — decides when a human takes over. Place the Work Guide so people can find their work, and watch runs from the Orchestration Runs list view.

Do that and you get the thing the platform was quietly missing: a durable, auditable place where humans, agents, and systems hand work to each other in a defined order, and you can see exactly where any given case is standing. If you’re designing that layer — especially the seam where Agentforce reasoning meets human approval and deterministic execution — talk to us. Getting the orchestration right so an agent acts inside a governed process, instead of next to one, is exactly the work we do.

Understanding the basics

What is Salesforce Flow Orchestration?

Flow Orchestration is a Salesforce automation feature for building durable, multi-step processes that span multiple users, transactions, and time. An orchestration is a sequence of stages, each containing steps; stages run sequentially while steps within a stage can run in parallel. Interactive steps assign a screen flow to a person and create a work item; background steps run an autolaunched flow with no user interaction. It coordinates many flows into one governed process — the layer above an individual flow. As of Spring ‘26 it’s a standard feature included in Enterprise, Performance, Unlimited, Einstein 1, and Developer editions, with no add-on or per-run cost.

Is Flow Orchestration free now?

Yes. In the Spring ‘26 release Salesforce made Flow Orchestration a standard feature with no add-on and no usage-based caps, included in Enterprise, Performance, Unlimited, Einstein 1, and Developer editions. Previously it was a paid capability with a small free run allowance (Salesforce Ben reports 600 runs per year) after which orgs bought additional-run bundles. That entitlement model is retired; ordinary edition-based Flow limits now apply. Flow-based Approval Orchestrations likewise consume no orchestration runs or automation credits.

Does Flow Orchestration replace approval processes?

Not by force. Salesforce introduced Approval Orchestration — approvals built entirely in Flow Builder with stages and steps — as the modern path, offering parallel approvers, dynamic routing, recall/withdraw, and better debugging that the legacy Approval Process lacks. But the legacy Approval Process has no announced end-of-life; Salesforce has simply stopped adding features to it (the December 31, 2025 end-of-support date applies to Workflow Rules and Process Builder, not Approval Processes). Build new approvals as Approval Orchestrations; leave working legacy approvals in place until they need a change.

---

Designing a process where an Agentforce agent, a human approver, and your back-end systems all have to hand work to each other in order — and be auditable end to end? Talk to us. Building the orchestration so the agent acts inside a governed process, not beside one, is the architecture we do.