Flow versions: how they work, and why you never overwrite the active one

August 3, 2026

Every Salesforce flow is really a stack of versions with at most one active at a time. That model is easy to ignore until a deploy replaces automation your business depends on - so here's how it actually behaves, and the habit that keeps you safe.

The rules of the stack

One active version per flow. The active version is what runs for triggers, screens, and subflows. Every other version just sits in the stack.
Editing never touches the active version. Open an active flow in Flow Builder, change anything, and Save creates a new version - the active one keeps running until you explicitly activate the new one.
Running interviews finish on the version they started on. Activate version 7 while someone is mid-way through a screen flow on version 6, and they complete on 6. Long-running scheduled paths behave the same way. You cannot break an in-flight interview by activating - which is exactly why activation, not saving, is the meaningful event.
Fifty versions, then a wall. A flow keeps at most 50 versions; past that, saving fails until you delete old ones. Teams that "save often" hit this earlier than they expect. Prune anything you'd never roll back to - but note you can't delete the active version, and deleting a version with paused interviews waits for them to finish.

Where deploys change the picture

Inside Flow Builder, activation is always a deliberate click. The Metadata API is the exception: a deployed flow whose XML says <status>Active</status> activates immediately on arrival - no human confirms anything in the target org. A CI pipeline or a copied deployment zip can silently swap the automation running in production.

That's the risk to engineer away, because a wrongly-activated flow doesn't fail loudly like broken Apex - it runs, doing the wrong thing to real records until someone notices.

The habit: deploy inactive, activate by hand

Deploy every flow with <status>Draft</status> (or Obsolete→ it lands inactive; Draft is the conventional choice). The new version joins the stack; the current active version keeps running untouched.
In the target org, open the flow, walk through the new version - debug it with real inputs if it's autolaunched.
Activate it yourself. Activation instantly deactivates the previous version, which stays in the stack as your one-click rollback.

The rollback story is the quiet payoff: because the old version survives, "undo" after a bad activation is activate the previous version - seconds, not a redeploy.

Quick reference - what runs afterwards

Save changes to an active flow → the old active version still runs (your edit became a new inactive version).
Activate a new version → the new version runs; the previous one deactivates but survives in the stack.
Deploy with status Draft → whatever was active before still runs (your deploy just joined the stack).
Deploy with status Active → your deployed version runs, immediately.

---

OrgTide enforces the safe habit mechanically: every flow it generates or deploys is forced to land as a new inactive version - regardless of what the AI produced - and activation stays a human click in Salesforce. The safety model →