Salesforce no longer supports Workflow Rules and Process Builder as of December 31, 2025. Your active ones still run, but there are no fixes. Migrate them in a sandbox with the Migrate to Flow tool, test each flow, then switch the old process off (Salesforce Help, 02-04-2026).

Clientell AI, the AI Salesforce admin, reads your org first, finds your Workflow Rules and Process Builder processes, and drafts each flow. Try the Clientell AI flow builder, or run the free, read-only flow audit first. For a shorter list to work from, see the cleanup checklist.

What happened to Process Builder and Workflow Rules, and what still runs?

Support ended on December 31, 2025. Salesforce says active rules and processes "may continue to function and execute existing automation". The change is that customer support is gone and bugs will not be fixed (Salesforce Help, 02-04-2026). Salesforce also says you can still activate, deactivate and edit them, and it recommends Flow Builder instead (Salesforce Help, Migrate to Flow Tool Considerations).

So nothing breaks on a set date. The risk is slower. Each release can change something around an old process, and no one at Salesforce will fix it for you. Read more in what Process Builder is and what Workflow Rules are.

Should we use Process Builder at all?

No, not for new work. Build every new automation as a flow. Keep an old process only while you have not yet migrated it. Admins have asked this question for years, and the answer is now clear (Salesforce Stack Exchange).

One more reason to move: Process Builder and Flow can fire on the same record and fight over order. Record-triggered flows let you set a trigger order from 1 to 2,000, with the API name as the tiebreaker (SFDC Developers, 30-06-2026).

How do I find every process and workflow rule in my org?

Make a list before you touch anything. You need the name, object, status, what it does, and who owns it.

In Setup, open Flows. The Type column marks Process Builder processes, so you can list every active one.
In Setup, search Workflow Rules and list the active rules per object.
For each one, note the trigger (create, edit, or both), the criteria, and the actions (field update, email alert, task, outbound message, Apex).
Note any scheduled actions or time triggers.
Mark anything that calls Apex, another flow, or an outside system.

Some orgs have a long list. A read-only scan of the org does this step faster than clicking through screens. Clientell AI does this scan without changing anything.

Which ones do I migrate first?

Rank by risk, not by age. Migrate the low-risk ones first so you learn the tool on safe ground, then take the risky ones with a test plan ready.

Rank	Type	Why this order
1	Inactive or unused processes	Do not migrate them. Delete them or archive the notes.
2	Workflow Rules with field updates only	The tool turns these into fast field update (before-save) flows (Salesforce Help).
3	Simple processes with one criteria and plain updates or creates	Easy to test. Easy to roll back.
4	Processes with email alerts, tasks or Chatter posts	Some actions need extra setup after the move.
5	Processes with scheduled actions	They migrate only if you select the single criteria they belong to.
6	Processes that call Apex, or that other flows call	The most links to other automation. Test last, with the most care.

Ask one question on each: does anyone still need this? Drop the ones nobody needs. You shrink the project before you start.

What can the Migrate to Flow tool not move?

The Migrate to Flow tool arrived in the Spring '23 release (PTC documentation). It handles many cases, not all. Salesforce lists these limits (Salesforce Help, Migrate to Flow Tool Considerations):

Item	What happens	What you do
Custom event or custom invocable type processes	Not supported. The tool handles record-triggered processes.	Rebuild by hand.
Processes with custom metadata types, or criteria that use a field from a related record	Not supported.	Rebuild by hand.
Cross-object references in formulas	Cannot carry over.	Rewrite with a Get Records element.
Recursion	Not fully supported. The migrated flow checks the record once.	Test it with the edge cases.
Scheduled actions	Migrate only if you pick the one criteria tied to them.	Migrate one criteria at a time.
Post to Chatter, Quick Action, Submit for Approval, Send Custom Notification	Migrate, but need extra setup.	Open the flow and finish the action.
Workflow rules with record types, tasks, relative dates, multiple currencies, or operators such as does not contain	Cannot migrate.	Add a Decision element, or use a Create Records element for the Task.

The tool also does not switch anything on or off. After a migration there is no "switch activations" button. You turn the flow on and the old process off yourself (Trailhead).

Migrate in the same org as the original, not in a middle org that you deploy from later (Salesforce Help, Migrate to Flow Tool Considerations).

What are the exact steps, in order?

These steps follow the Trailhead project and the Salesforce Help page. Do them in a sandbox first.

In the sandbox, open Setup and search for Migrate to Flow.
Select the process or workflow rule.
For a process, pick the criteria to move. You can move all criteria into one flow or move them into separate flows.
Click Migrate to Flow.
Click Test in Flow Builder to open the new flow.
In the Start element, check the setting for what to optimize the flow for. For simple field updates on the same record, choose Fast Field Updates, then save as a new version.
Test the flow (see the next section).
Activate the new flow.
In Process Builder or Workflow Rules, deactivate the original.

Do steps 8 and 9 close together. If both run, the same field can be updated twice, and actions such as emails can fire twice.

How do I rebuild one as a flow and test it before it goes live?

Test in the sandbox with records that match each branch of the old logic.

Write down what the old process did for a record that meets the criteria, and for one that does not.
Create or pick test records for both cases. Include one that triggers each action: field update, email, task.
Run the new flow with the old one off. Check that every field, email and task matches your notes.
Run it on a bulk load, for example 200 records, to check it does not hit limits.
Check the debug log or the flow's run history for faults.
Ask the process owner to confirm the result.

Then move the flow to production the way you move other changes. If you use change sets, validate in production first. Active flows arrive as inactive, so you turn them on after the deploy. Our Flow Builder best practices post covers naming, fault paths and order.

How do I roll back if the new flow misbehaves?

Plan the way back before you go live.

Do not delete the old process. Deactivate it. You can turn it back on.
Keep a note of the old process version and the date you switched.
If the flow misbehaves, deactivate the flow first. Then reactivate the old process.
Fix the flow in the sandbox and repeat the test.
Delete the old process only after the flow has run clean for a period you chose.

Process Builder versions can also cause trouble in deploys. One admin saw a new inactive version appear after each deploy with the CLI, even with no change (Salesforce Stack Exchange). Check the version list after each deploy.

Clientell AI offers a read-only scan, sandbox testing, and rollback on Platform deployments. See security and privacy.

Try it in Clientell AI: "Find every Process Builder and Workflow Rule on the Opportunity object, rank them by risk, and draft the flow for the riskiest one without changing anything yet." Start the 14-day trial, no card.

Want a list first? Run the free, read-only flow audit. Clientell MCP is $249 a month and Clientell Platform is $500 a month. See pricing.

FAQ: common questions about Process Builder and Workflow Rules

What is Process Builder in Salesforce?

Process Builder is the point-and-click tool that ran actions when a record changed. Flow replaces it. See the Process Builder glossary page.

What are Workflow Rules in Salesforce?

Workflow Rules are the older automation tool. They run field updates, email alerts, tasks and outbound messages when a record meets criteria. See the Workflow Rules glossary page.

Will my old processes stop working?

Salesforce says they may continue to run. It gives no support and no bug fixes for them.

Can one process become more than one flow?

Yes. You can move each criteria to its own flow. Set a trigger order if the flows touch the same fields.

Does the Migrate to Flow tool deactivate the old process?

No. You activate the flow and deactivate the process yourself.

Sources

Last updated: October 9, 2026

#Process Builder#Workflow Rules#Salesforce Flow#Migrate to Flow#Salesforce Automation