Flow · the 50 version limit
Every deployment of the flow fails.
It is full: 50 versions is the ceiling.
A Salesforce flow can hold at most 50 versions, and once it has 50, every save and every deployment of it fails until older versions are deleted. The error rarely names the limit: through the Metadata API it arrives as a field integrity exception with no element and no explanation. Below: the one query that recognises it, the clean-up used in a coworking and real estate group’s org, and what a full flow says about the automation around it.
Salesforce Help and the Tooling API reference read on 1 November 2026. Reviewed 3 November 2026.
The limit
What is the maximum number of versions of a Salesforce flow?
Fifty. Salesforce Help lists 50 versions per flow in every edition, from Essentials and Professional to Enterprise, Unlimited and Developer. The ceiling counts the versions kept, active or not, so a flow edited often, or changed in every release, reaches it long before it looks old.
The figure is in Flow Limits per Org, under General Flow Limits, next to two limits per org that are rarely the ones an org hits:
| Limit | Essentials or Professional | Enterprise, Unlimited, Performance, Developer |
|---|---|---|
| Versions per flow | 50 | 50 |
| Active flows per flow type | 5 | 2,000 |
| Total flows per flow type | 5 | 4,000 |
The version number on the screen is not the count. In the group’s org the oldest versions still kept on the flow that hit the limit were numbered in the nineties, because older ones had been deleted before. The only reliable figure is the one a query returns.
The symptom
Why does a flow deployment fail with a field integrity exception?
Often because the flow is already at 50 versions. A deployment of a changed flow must create version 51, Salesforce refuses, and the Metadata API reports a field integrity exception with no element, no line and no word about the limit. Deploying the unchanged file still reports success, because nothing new had to be created.
So count before you read your own XML. In the Developer Console query editor, tick Use Tooling API and run:
If it says 50, that is the error. If you want the real message anyway, the Tooling API gives it: in that org, posting the same flow to the Flow object returned a response that named the element and the field. When the flow XML is converted to JSON for that call, leave out the elements marked xsi:nil, or they arrive as empty strings that Salesforce reads as filled in.
In the group’s org a button flow on deals sat at exactly 50. Seven deployments failed before anyone looked for anything but a fault in a change that had none. One count found it, the 12 oldest obsolete versions were deleted, and the next deployment passed on the first attempt.
The clean-up
How do you delete old flow versions without losing one?
In four steps, in this order. Save every version you will delete as its own file, because a deleted version has no way back. Delete the paused and failed interviews that hold those versions. Delete the versions, oldest first, never the active one. Then count again by query, because the command output is not proof.
The rule behind the second step is in the Flow object of the Tooling API reference, which also notes that updating a flow version in fact deletes it and creates a new one with a new Id. The steps below are the order that held up across the group’s orgs.
- 01
A file for every version before anything is deleted
Each version is read from the Tooling API Flow object by its Id and saved as its own file. Treat a deleted version as gone: the backup is the only way back. Source control holds what was deployed from it, not the versions somebody saved in Flow Builder.
- 02
Interviews before versions
The Tooling API reference allows deleting a version only when it is not active and has no paused interviews; those have to finish or be deleted first. In the group’s org failed interviews held versions as well, and a deletion run stopped halfway on them. The link from interview to version sits in the interview’s FlowVersionViewId field.
- 03
Obsolete versions, oldest first, through the Tooling API
Delete from the oldest obsolete version up, and keep the active one and the newest drafts. A flow with no active version is left alone entirely, because deleting every version deletes the flow itself.
- 04
A count, not the command output
One early attempt sent REST DELETE calls through the command line: forty calls, no error on screen, and the control query still showed the same 50 versions. The command needed a body it never got, and the message was cut off by the filter that shortened the output. Deleting each record through the Tooling API worked: 45 versions removed across the sandboxes with zero failures, each one confirmed by query.
What else looks like success
Three flow deployments that report Succeeded and change nothing.
The version limit is the loudest of four traps met in the same org, all with one cure: read the state of the flow from the org after every deployment, never from the deployment report.
- 01
Succeeded, and the old version still runs
In the group’s production org a deployed flow landed as a new version without becoming active. Activation was a separate component, the flow definition, which is also the way back: point it at the previous version and the change is undone.
- 02
Retrieve gives the latest version, not the active one
A retrieve returned the newest version of the flow, a draft, while production ran an older one. A fix built on that file would have started from work nobody had approved.
- 03
A number with no scale
A Number variable deployed without a scale reported Succeeded and left an invalid draft. Success on the deployment meant the XML was readable, not that the flow could run.
What 50 versions is a symptom of
A flow at 50 is a flow nobody owns.
Fifty versions means fifty saves, and in most orgs they come from several people changing the same flow for different reasons, with no record of which version did what. That is the pattern behind changes that break other things: automation written by several people over several years, firing on the same record in an order nobody has traced. Deleting old versions unblocks the deployment today. It does not tell you which of the versions left is the one the business depends on.
The repair that ends it is an automation clean-up: every flow listed with what it does and who changes it, overlapping flows merged, the order of execution written down, and the same records checked before and after. Where nobody can say any more what the flows do, the problem has already become nobody being able to change anything, and the clean-up starts with writing it down.
Asked often enough to answer here
Questions
- Q
Can I delete the active version of a flow?
No. The Tooling API reference allows deleting a version only when it is not active and has no paused interviews. Activate the version you want running first, then delete the old one. If the flow has no active version at all, leave it alone, because deleting every version deletes the flow.
- Q
Does deleting old versions stop anything that is running?
The active version keeps running. What a deletion can touch is work paused on an old version, such as an interview waiting on a scheduled step or a screen a user left halfway. Those interviews must finish or be deleted before the version goes, so look at them and decide rather than delete in bulk.
- Q
How do we stop reaching the limit again?
Count versions as part of every release, so a flow at 40 is cleaned before it blocks a fix. Deploy a flow only when it changed. Give each flow one owner who decides which versions stay. The count stays low, and the history that remains is history somebody can explain.
A fixed price on a written scope: automation audit, consolidation onto Flow and a documented order of execution, about 4 weeks elapsed. Documentation and sixty days of support after handover are in the price.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 3 November 2026.
Read next
The question that usually comes after this one.
- 01
Changes break things nobody expected
Automation written by several people over several years. Read the cause, the check you can run yourself, and what it costs to put right.
- 02
Sales Cloud Audit: Eight Checks, €650 Day
A Sales Cloud audit in eight checks your admin can run, or done for you: €650 for one day against your exports, €4,875 to fix all eight.
- 03
Is Claude Code Safe in a Salesforce Org?
Whether to let Claude Code work in your Salesforce org: what Salesforce and Anthropic enforce, what they leave to you, and the guardrails I run on my own org.