Salesforce Flow Orchestrator: Now Free for Everyone

For years, Flow Orchestration sat in that frustrating tier of Salesforce features that solved real problems but cost extra. Admins would design beautiful multi-stage business processes in their heads, then watch them die the moment procurement saw the add-on price tag. That whole conversation just changed. As of February 18, 2026, Flow Orchestration is a standard Flow type, included in your existing Salesforce edition with no separate license required.

If you've been using regular Flows to limp through approval-heavy, multi-team processes, this is the upgrade you've been waiting for. I've rebuilt three orchestrations in client orgs over the last few weeks and the difference between stitching together record-triggered Flows with custom flags vs. using a proper orchestration is honestly a little embarrassing in hindsight.

Let me walk you through what Flow Orchestrator actually is, why it matters now that it's free, and how to decide when to use it instead of a regular Flow.

What Flow Orchestrator Actually Is

The simplest way I can describe it: a regular Flow is a specialist that handles one task. Flow Orchestrator is the conductor that strings multiple Flows together into a single, governed business process that can span days, weeks, departments, and dozens of users.

You build orchestrations from three building blocks:

• Stages: groups of steps that run in sequence. Only one stage runs at a time, and you set the conditions that mark a stage complete.
• Steps: the individual units of work inside a stage. Steps can run sequentially or in parallel within the same stage.
• Flows: the actual screen flows or autolaunched flows that get executed by each step.

There are three types of steps you can drop into a stage:

1. Interactive steps assign a screen flow to a specific user, group, or queue. They wait for that human to act.
2. Background steps run an autolaunched flow synchronously or asynchronously, no user input needed.
3. MuleSoft steps call out to a MuleSoft operation, which is how you tie external systems into the same orchestration.

If you've ever tried to build a 12-step employee onboarding "Flow" that bounces between HR, IT, the hiring manager, and finance, you already understand why this matters. Without orchestration, you end up with a mess of record-triggered flows, custom checkbox fields acting as state, and email alerts held together by hope. With orchestration, the engine itself tracks where the process is, who owns the next step, and what happens when something gets stuck.

If any of these terms feel new, salesforcedictionary.com has clean definitions for stage, step, screen flow, and autolaunched flow that I'll usually skim before designing anything more complex than a record trigger.

Why "Free" Is the Headline

I want to spend a minute on the licensing change because the impact is bigger than it sounds. Flow Orchestration originally launched in Winter '22 as a paid SKU. The price varied by edition and customer, but it was enough that most mid-market orgs I worked with quietly avoided it. They'd do the demo, nod, and then go build it in regular Flows with a "we'll revisit it later" note that never came back up.

As of Spring '26, that gate is gone. Orchestration is now a standard Flow type subject to your existing edition's Flow limits, just like screen flows, record-triggered flows, and autolaunched flows. If your edition supports Flows, it supports orchestrations.

What this changes practically:

• No more business case slides. You don't have to justify another line item to use it.
• No more "wait for budget approval". You can prototype an orchestration in a sandbox tonight.
• Easier handoff to consultants and ISVs. Implementation partners can include orchestrations in scoped projects without negotiating around an add-on.

The first thing I'd tell any admin reading this: open Setup, search for Orchestrator, and just look around. You probably already have it enabled.

When to Use Flow Orchestrator (and When to Stay With Regular Flow)

This is where I see people overcorrect. Once admins discover orchestration, they want to use it everywhere, including for things that should stay as a single record-triggered flow. Don't do that. Keep your tooling proportional to the problem.

Reach for Flow Orchestrator when:

• The process touches multiple users or roles who each need to do something.
• It runs over multiple sessions or days, not seconds.
• Different stages need different access (HR sees one thing, IT sees another).
• You need a clear audit trail of who did what, when.
• Logic involves parallel work that converges later (think: appraisal and document collection running at the same time during a mortgage approval).

Stick with a regular Flow when:

• One trigger, one process, one user (or no user).
• Everything completes in seconds, synchronously.
• You're updating fields on a single record or creating related records.
• It's a quick screen flow embedded on a Lightning page.

A real-world test I use: if I find myself adding a custom "Process_Stage__c" picklist on a record to track where I am in a workflow, I should probably be using orchestration instead. That picklist is just me reinventing stages, badly.

Practical Use Cases That Actually Work

Three patterns I've seen succeed once teams get past the demo phase:

Employee onboarding. New hire record gets created. Stage one assigns an interactive step to HR to confirm details. Stage two fans out to IT (laptop, accounts) and Facilities (badge, desk) in parallel. Stage three loops in the hiring manager for a Day 1 check-in. Each stage waits for its conditions before moving forward, and you get a single record showing exactly where the process is.

Incident-driven case surge. Service Cloud is good at managing one case. It's less good at coordinating a response across agents, ops, and engineering when fifty cases land at once on the same root cause. Orchestration lets you wrap that response: stage one classifies and groups, stage two assigns an interactive step to ops to confirm root cause, stage three runs background steps to mass-communicate to affected accounts.

Order fulfillment with handoffs. The classic ugly one. Sales closes, finance bills, ops fulfills, AR follows up. Without orchestration, this is a mess of opportunity record types, stage automation, and Slack pings. With orchestration, each function is a stage, hand-offs are step transitions, and a stuck order is visibly stuck on a specific stage rather than mysteriously dropped.

Approval-heavy processes. Spring '26 also keeps the Flow Approval Processes story moving forward, and approval steps are first-class citizens in orchestrations. An approval step is just an interactive step with a screen flow, an approver, and an approvalDecision output variable that resolves to Approve or Reject. You can chain approvals across stages, fork the path based on decision, and lock records during the wait. It is, finally, the modern replacement for legacy approval processes.

How to Get Started Without Breaking Anything

Here's the path I'd suggest if this is new to you:

1. Trailhead the basics. The Orchestrator Basics module is short and worth running through, even if you're an experienced Flow builder. Stages and steps have their own quirks (entry/exit conditions, parallel vs. sequential, Decision elements between stages) that aren't obvious from regular Flow experience.
2. Pick a small process. Don't start by re-platforming your big approval workflow. Pick something with three stages and four to six steps. Onboarding for a single role is a great first project.
3. Build component flows first. Each step in an orchestration calls a flow. Build and test those flows independently first so you're not debugging two layers at once.
4. Use the Work Guide. Interactive steps surface in the user's Work Guide on the record they touch. Make sure your screen flows are labeled clearly because users will see step names in the UI.
5. Watch your governor limits. Orchestrations are still subject to Flow limits. Long-running, high-volume orchestrations need the same care as any complex automation.

If you want a glossary of every Flow term mentioned here, including pause elements, Decision elements, Work Guide, and approval orchestration, I keep coming back to salesforcedictionary.com because it covers the newer 2026 vocabulary that older blog posts haven't caught up to yet. Useful when you're trying to remember the difference between an autolaunched flow and a record-triggered flow at 11pm.

Final Thoughts

The biggest barrier to Flow Orchestrator was never the technology. It was the SKU. With that gone, the only reason not to use orchestration for the right problems is the learning curve, and the learning curve is genuinely smaller than approval processes were ten years ago.

If you've been holding off on cleaning up your messiest cross-team processes because the tooling felt too brittle, this is the cue to revisit. Pick one orchestration, build it small, ship it, and use what you learn to take on the next one.

What process are you thinking of moving to Flow Orchestrator first? Drop it in the comments. I'm curious what people are tackling now that the cost question is off the table, and I'll share notes from a few of the rebuilds I've been working through.

Sources I leaned on for this post: Salesforce Admins blog ("Flow Orchestration Is Now a Standard Flow Type"), Salesforce Ben's Flow Orchestrator guide, Salesforce Help docs on stages and steps, and the Trailhead Orchestrator Basics module. For the broader vocabulary around Flow types, salesforcedictionary.com has been my go-to terminology reference.