To clean up Salesforce flows, list every flow, delete obsolete versions, migrate Process Builder and Workflow Rules, apply one naming pattern, add fault paths, test in a sandbox, then deploy in small batches. Do it in that order, because each step makes the next one safer.
Clientell AI, the AI agent for Salesforce admins and teams, maps every flow in your org and what it touches, drafts the cleanup, and changes nothing until you approve. Start with the free Flow audit, which is read-only.
Step 1: How do I list every flow in my org?
Start with a full inventory. In Setup, open Flows and sort by Last Modified. For a list you can export, run this query in the Developer Console (check the Use Tooling API box):
SELECT ApiName, Label, ProcessType, ActiveVersionId, LastModifiedDate FROM FlowDefinitionView
Copy the result into a sheet. Add three columns: owner, object touched, and decision (keep, fix, retire). For each flow, write one line on what it does. If you cannot write that line, the flow goes on the "investigate" list.
Step 2: How do I find inactive flows and old versions?
A flow with an empty ActiveVersionId has no active version. It does nothing today. Check why before you delete it. It may be a draft someone is still building.
Old versions are a separate problem. Every save of an active flow can leave an older version behind. Find them with this Tooling API query:
SELECT Definition.DeveloperName, VersionNumber, Status FROM Flow WHERE Status = 'Obsolete'
In Setup, open the flow, then delete obsolete versions you no longer need as a rollback point. Keep the previous version of any flow you changed this month. Export a flow's metadata before you delete the last copy of anything.
Step 3: What do I do about Process Builder and Workflow Rules?
Migrate them. Salesforce no longer supports Workflow Rules and Process Builder as of 31-12-2025. They may keep running, but support is gone and bugs will not be fixed (Salesforce Help). Salesforce recommends moving them to Flow Builder and offers a Migrate to Flow tool.
Use this order:
- List every active process and workflow rule, grouped by object.
- Pick one object at a time. Merge its rules into one record-triggered flow where you can.
- Run the Migrate to Flow tool on one rule and read the result. Treat it as a first draft.
- Test the new flow in a sandbox with the old rule still active there.
- Turn off the old rule, activate the flow, and watch the object for a week.
Never run an old rule and its replacement together in production. Both will fire on the same save.
Step 4: How should I name flows?
Pick one pattern and apply it to every flow. For example: Object_Trigger_Purpose, such as Opportunity_AfterSave_SetStage or Case_Scheduled_CloseStale. The name should tell you the object, when it runs and why.
Rename in the Label, then check the API name. Changing an API name affects anything that calls the flow, such as a subflow or Apex. Search for callers first. Put a short description on every flow, so the next admin does not have to open it.
Step 5: Where do fault paths go?
Put a fault path on every element that reads or writes data: Create Records, Update Records, Delete Records and Get Records. Without one, a failure shows the user a generic error and your team learns nothing.
A good fault path does two things. It logs the error somewhere you check, such as a custom object or an email to the admin queue. It then ends the flow in a clear way. Include the flow name and the record Id in the message, so you can find the failing record.
Step 6: How do I test a flow cleanup in a sandbox?
Never test cleanup in production. Refresh or use a sandbox that holds a copy of the objects the flows touch. Then:
- Open each changed flow in Flow Builder and use Debug with a real record.
- Test the paths that people forget: a record with empty fields, a record owned by an inactive user, and a bulk update of 200 records through Data Loader.
- Check the same reports before and after.
- Check validation rules and other flows on the same object. Two flows that update the same field can overwrite each other.
Write down what you tested and what you saw. You will need it for the approval.
Step 7: How do I deploy flow changes safely?
Deploy in small batches. One object at a time is a good size. Deactivate before you delete: turn a flow off for a full business cycle, such as a month-end close, to catch the automation that only runs then. Delete only after nothing breaks.
Keep a way back. Export the flow metadata first, and keep the old version until the next release passes without complaints. Tools such as DevOps Center, Gearset or Clientell Platform can deploy for you. For a comparison, see our guide to Salesforce DevOps tools.
Step 8: How do I keep flows clean afterwards?
Add a short rule to your change process. Every new flow gets a name, a description, a fault path and one owner. Review the flow list each quarter. Retire anything with no active version and no caller.
For the wider picture of automation debt, read our technical debt guide.
Where does Clientell AI help with flow cleanup?
The hard part of cleanup is knowing what a flow touches. Clientell AI builds a context graph of your org, a live map of every object, field, flow and permission. It finds every flow, shows which fields and records each one reads and writes, and lists what would break if you retire it.
Then it drafts the changes: the migration, the rename, the fault path. You review each one. Nothing runs until you approve it, and Platform deployments have rollback. You can also run it from your own Claude client through Clientell MCP. Read more on security and privacy.
Try it in Clientell: "Scan my org in read-only mode and list every inactive flow, every flow without a fault path, and every active Process Builder process, with the objects each one touches."
Start the 14-day trial, no card needed. Clientell MCP is $249 a month and Clientell Platform is $500 a month. See pricing.
Frequently Asked Questions
Is it safe to delete inactive Salesforce flows?
Only after you check why they are inactive and confirm nothing calls them. Deactivate first, wait a business cycle, export the metadata, then delete.
Do Workflow Rules and Process Builder still work?
They can still run, but Salesforce ended support for them on 31-12-2025. Support is gone and bugs will not be fixed, so migrate the ones you rely on.
How many flows should one object have?
Fewer is easier to reason about. Many teams aim for one record-triggered flow per object and trigger type, and move branching inside it. Pick a rule and document it.
What is a flow fault path?
It is the route a flow takes when an element fails. Without it, the user sees a generic error and you get no useful log.
Can an AI agent clean up flows for me?
Yes, if it reads your org first, drafts each change and waits for your approval. Never let a tool edit flows in production without review.
Last updated: October 6, 2026
