Moving Process Builder and Workflow Rules to Flow

Where things stand

Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Active rules and processes keep running after that date, but Salesforce no longer provides support cases or bug fixes for them. For a regulated firm that means every remaining rule is unsupported automation touching client data, and the sooner it is replaced with something Salesforce will stand behind, the better your position at the next review.

Flow Builder is the replacement. Record-triggered flows with entry conditions and Fast Field Updates run considerably faster than the older tools, keep all automation in one place, and let you control execution order with Flow Trigger Explorer.

Inventory first

1. In Setup, open Workflow Rules and sort by the Active column. Export the list with object, criteria, actions and last modified date.
2. Do the same for Process Builder, sorting by Status for Active processes. Note which processes invoke flows or other processes.
3. For each item, record the business owner and whether anyone can explain what it does. Rules nobody can explain are candidates for retirement rather than migration.
4. Group the list by object. You will build one or two record-triggered flows per object, not one flow per old rule.

Use the Migrate to Flow tool where it fits

The Migrate to Flow tool in Setup converts a workflow rule or a process into a flow. The sequence Salesforce documents is: select the rule or process, choose the criteria to migrate, run the migration, review anything flagged Needs Review, test in Flow Builder, activate the flow, then deactivate the original. A workflow rule that contains only field updates on the same record is converted to a fast field update (before-save) flow, which is the best outcome.

Processes usually migrate partially. The results screen lists actions that need configuration in Flow Builder before the migration is complete. Treat the generated flow as a starting draft and expect to rework it.

What the tool does not handle

The Trailhead project on automation changes lists the gaps. Plan to rebuild these by hand:

• Workflow rules with criteria but no actions, rules referencing global variable fields, fields on related records or record types, and rules using Does Not Contain, Includes, Excludes or Within operators.
• Greater than or less than comparisons on picklists, formulas using functions such as HOUR, TIMENOW or $RecordType, task actions, relative date values, and multiple currencies.
• Processes started from a platform event or invoked by another process, scheduled actions in processes, and field traversals.
• Recursive processes, which after migration evaluate the record only once.
• Invocable actions, which cannot be partially migrated.

Order of operations we use

1. Design per object. Sketch one before-save flow for same-record field updates and one after-save flow for everything else (related records, emails, outbound messages, subflows). Fold the old rules into these as decision branches.
2. Migrate or rebuild in a sandbox. Never debug against production data. Use a full or partial copy sandbox that has realistic records.
3. Replace cross-object patterns. Old processes often chained field updates to fire other rules. In Flow, do the work directly or call a subflow.
4. Set execution order. Open Flow Trigger Explorer and assign priorities to record-triggered flows on each object. Flows and workflow rules time their execution differently, so the old implicit order is gone.
5. Move callouts and pauses to asynchronous paths. Any former invoke-flow action that made an external callout or paused should run on a scheduled or asynchronous path.
6. Test with a written script. One test case per old rule, with the record before and after. Keep the results; they are part of your change evidence.
7. Activate the flow, then deactivate the rule, then watch. Deactivate rather than delete for the first release cycle so you can roll back quickly.
8. Delete the old automation in a later release once the flow has run clean through a month end.

What breaks during migration

What we recommend for regulated firms

• Treat the inventory as a control document. It should show each rule, its replacement flow, the test evidence and the deactivation date. That is what an auditor will ask for.
• Retire before you migrate. A meaningful share of old rules are dead. Removing them reduces the surface you have to test and explain.
• Keep suitability, disclosure and approval logic in named flows with descriptions that say what regulation or policy they support, so the next admin doesn't have to reverse-engineer them.
• Deploy through your release checklist with a sandbox sign-off, not directly in production from the Migrate to Flow screen.