Salesforce ended support for Workflow Rules and Process Builder in 2025. Ended support does not mean switched off. In many orgs they are still firing on every save. Source: Salesforce Help, Workflow Rules and Process Builder end of support.
This checklist is a way to clear them out in five steps. Read-only first. Nothing is deleted or rebuilt until a person says yes.
Why a one-click conversion is not the plan
Salesforce has a Migrate to Flow tool. It converts rules. One admin consultancy puts the limit plainly: it "won't tell you which ones you should convert" (LinkedIn, 29-08-2026). Another writer says it "will happily turn 100 Process Builders into 100 Flows. That is the problem, not the solution." (LinkedIn, 30-06-2026).
So the order matters. Decide what to keep first. Convert second.
Step 1. Count them
You cannot plan a cleanup you cannot size. One public gut check asks the question directly: "do you know how many active Workflow Rules and Process Builder processes still run?" (LinkedIn, 15-08-2026).
- List every active Workflow Rule, by object. (Setup, Workflow Rules.)
- List every active Process Builder process, by object. (Setup, Process Builder.)
- Write the count per object in one sheet. Add a column for who owns it.
- Mark how many are active and how many are inactive. Inactive ones are the easiest drops.
- Note which objects also have flows, triggers or other rules. Several automations on one object can fight each other.
Step 2. Rank them by risk
Not all of them matter equally. Rank each one by what happens if it breaks or fires wrong.
- Sends email or alerts to people. Check the recipients. Some of them email people who left years ago.
- Updates fields on other records. A wrong update spreads.
- Creates records (tasks, cases, child records). Duplicates pile up.
- Calls Apex, an outbound message or an integration. An outside system depends on it.
- Touches money, ownership or approval fields. Highest care.
- Only sets a convenience field. Lowest risk.
Give each rule a rank: high, medium or low. Start the rebuild with high.
Step 3. Decide what to drop before you convert
Every rule you drop is one less flow to build, test and keep.
- Has it fired in the last 90 days? If you cannot tell, find out first (debug logs, flow and process error emails, or the record history it writes to).
- Is the field it sets still used in a report, a page layout or another automation? If not, it is a drop candidate.
- Does another flow or rule already do the same job? Keep one.
- Is the person or team it notifies still there?
- Does anyone know why it exists? If nobody does, ask around once, then park it as "drop after a sandbox test".
For each rule write one line: keep, drop or ask. Write the why, not only the what. A field name tells you what. It does not tell you why anyone made it.
Step 4. Rebuild the keepers as flows you approve
- Rebuild each keeper as a record-triggered flow, one per object and trigger where you can. Fewer flows per object are easier to reason about.
- Use the converted flow from the tool as a first draft only. Read it before you accept it.
- Give each flow a name and a description that says why it exists.
- Have a person approve each flow before it goes near production. The author should not be the only reviewer.
- Build and test in a sandbox first.
Step 5. Test each one, then retire the old rule
- Test the new flow with a record that should trigger it and one that should not.
- Test with a bulk load, not only one record.
- Compare the old and new behavior side by side. Salesforce's flow version comparison helps when you edit an existing flow.
- Check that the old rule and the new flow are not both active. Two copies fire twice.
- Turn the old rule off. Keep it for one release cycle before you delete it, so you can switch it back on.
- Write down what you changed and why.
How to keep it from coming back
- Re-run the count every quarter. New rules appear when people are in a hurry.
- Keep one owner per object.
- Write the why next to every new automation.
Run the count and the ranking automatically
The count and the object overlap are part of what the free Salesforce foundation check does, read-only, with a report in 24 hours. Clientell AI, the AI agent for Salesforce admins and teams, reads your org first, drafts each rebuilt flow, and changes nothing until you approve.
For the wider list of flow problems, see 15 Salesforce Flows Quietly Tanking Your Org.