Salesforce 'Active Flow Cannot Be Overwritten' — and the Silent Deploy That's Worse
You change a Flow, deploy it, and Salesforce stops you:
This flow is already active and can't be overwritten. Deactivate it first or save as a new version.
Or the deploy goes green — and the flow still isn't running.
Why flows are deceptive on deploy
A Flow is versioned: every deploy of a changed flow body creates a new version, and at most one version is Active at a time. A separate component — the FlowDefinition — decides which version is active. That split between "the version you shipped" and "the version that's running" is where flow deploys go wrong, in two different ways.
The loud one (mostly legacy)
"...already active and can't be overwritten" fires when a deploy tries to modify the active version in place. Under Salesforce's modern auto-versioning this rarely happens — a redeploy just lands a new version and leaves the active one alone. You'll still meet it on legacy Process Builder or some change-set paths. The fix there is in the message: deactivate the flow first, or let it deploy as a new version.
The silent one (production-only, and worse)
Here's the part that catches teams. In a sandbox, a flow always deploys active — Salesforce lets you activate a new version freely. In production, by default, it doesn't. The new version lands inactive, the deploy reports success, and the old version — or nothing — keeps running. The automation you thought you shipped quietly didn't change.
Activating a flow on deploy to production is gated behind an org setting, "Deploy processes and flows as active," and that setting demands 75% of your flows and processes be covered by Apex tests before it'll let anything deploy active — the flow analogue of the 75% Apex rule. So most orgs leave it off, and live with the silent landing.
The result: a green production deploy and a flow that isn't live. The loud error everyone prepares for barely fires anymore. The costly one leaves no error at all.
The fix
A flow's active version is controlled by its FlowDefinition's <activeVersionNumber>. After a new version lands in production, something has to set that to the version you just shipped — either by turning on "Deploy processes and flows as active" (and carrying the test coverage it demands), or by activating the new version as a deliberate step after the deploy.
The rule to internalize: a green production deploy doesn't mean your flow is running. Check the active version, every time.
How mtdt.io deploys and activates in one step
mtdt.io closes the gap with an Activate flows after deployment option on the deploy. It appears where it matters — on a production target (in a sandbox the new version already activates, so there's nothing to add). Switch it on, and once the deploy succeeds mtdt reads each flow's just-landed version in the target and activates exactly that version. The result card then shows Flows activated: X / N — a green deploy that means the flow is actually live.
A few things it gets right:
- Per-flow control. Activate every flow in the deploy, or open Configure and leave specific ones inactive.
- It activates the target's version, never a number from source. Flow version numbers don't carry across orgs — shipping a hard-coded
FlowDefinitionfrom your repo is how you get "invalid version number." mtdt reads the version the target actually produced and activates that, so the cross-org trap never comes up. - The 75% gate stays Salesforce's call. If production's coverage gate blocks a flow from activating, mtdt leaves that one inactive and tells you which flow and why — the rest of the deploy still goes through.
And if a release goes wrong, rollback understands activation too. mtdt records each flow's active version before the deploy, and on rollback restores it: reactivating the previous version for flows that already existed, and deactivating (then removing) flows the deploy created.
Before and after, the status stays in plain sight — flows carry an Inactive badge in the deploy table, and HealthCheck flags any flow whose latest version isn't the active one, so the silent-inactive aftermath gets caught across the whole org. For undoing a release cleanly, see One-Click Rollback.
FAQ
Why does a Salesforce flow deploy show success but not actually run? In production, a new flow version lands inactive by default unless the org setting "Deploy processes and flows as active" is turned on — and that setting requires 75% Apex test coverage of flows and processes before Salesforce allows it. The deploy reports success because the version landed correctly; it's just not the version marked active, so the old version (or nothing) keeps running.
What does "this flow is already active and can't be overwritten" mean? It fires when a deploy tries to modify the currently active flow version in place. Under Salesforce's modern auto-versioning this is rare — a redeploy just creates a new version and leaves the active one alone — but it can still happen on legacy Process Builder or some change-set paths. The fix is to deactivate the flow first or let it deploy as a new version.
How does mtdt.io make sure a deployed flow is actually active in production? mtdt.io has an "Activate flows after deployment" option that appears for production targets. Once the deploy succeeds, it reads each flow's just-landed version in the target and activates exactly that version, and the result card shows "Flows activated: X / N" so a green deploy means the flow is confirmed live.
Can I activate some flows in a deployment but leave others inactive? Yes — mtdt.io's activation is per-flow. You can activate every flow in the deploy, or open Configure to leave specific ones inactive.
What happens if a flow can't be activated because of Salesforce's 75% test coverage gate? mtdt.io leaves that flow inactive and tells you which flow and why the gate blocked it, while the rest of the deployment still goes through. The 75% coverage requirement itself is Salesforce's rule, not something mtdt.io can bypass.
Does rollback also undo flow activation? Yes. mtdt.io records each flow's active version before the deploy, and on rollback it reactivates the previous version for flows that already existed, and deactivates (then removes) any flows the deploy created.
Stop shipping flows that don't run
Deploy to production and let mtdt.io activate the new versions in the same step — so a green deploy means a live flow.
Log in to mtdt.io and deploy your flows.
Was this page helpful?
Let us know how we did