Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025. Your active rules and processes still run, but Salesforce no longer provides customer support or bug fixes for them, and it recommends moving that automation to Flow. The work has four parts: inventory what is active, decide what to retire, migrate the rest (the Migrate to Flow tool handles many simple cases), and test each object's automation as a whole before switching it on.
What end of support actually means
Nothing switched off on January 1, 2026. Salesforce's help article is explicit that active Workflow Rules and Process Builder processes continue to run as they do today. What changed is the safety net: if one of them misbehaves after a release, Salesforce support will not investigate it and the underlying bug will not be fixed. The risk grows quietly with every release, because new platform behavior is tested against Flow, not against tools that are out of support.
That makes this a planned piece of maintenance rather than an emergency, as long as you start. Orgs that have run for years often carry more of this automation than anyone remembers, and a migration touching dozens of objects takes time to test properly. Salesforce itself warns that, depending on complexity, the move may take significant time and testing.
Step 1: inventory what is running
Salesforce's instructions for finding affected automation are simple: in Setup, open Process Automation, then Workflow Rules, and sort by the Active column; do the same in Process Builder and sort by Status. Export or copy both lists into a spreadsheet, then add the columns that will drive your plan.
- Object and trigger: which object it runs on, and whether it fires on create, on every edit, or when criteria are first met.
- What it does: field updates, email alerts, tasks, outbound messages, record creation, calls to Apex or other flows.
- Time-based actions: anything scheduled for later, and whether items are waiting in the queue right now.
- Business owner: the person who can say whether the rule is still needed.
- Overlap: other Flows, Apex triggers or validation rules on the same object that touch the same fields.
- Evidence of use: recent emails sent, fields actually updated, or reports that depend on the result.
Expect to find rules nobody can explain, rules that contradict each other and rules for processes the business stopped using years ago. Retiring those is the cheapest migration there is. Deactivate first, watch for a few weeks, and delete only after nobody has missed them.
Step 2: use the Migrate to Flow tool where it fits
Salesforce provides a Migrate to Flow tool, found by searching Setup for "Migrate to Flow". You select a workflow rule or process, click Migrate to Flow, and the tool builds an equivalent record-triggered flow. From there you can test it in Flow Builder, then use Switch Activations, which deactivates the old rule and activates the new flow in one step. A workflow rule that contains only field updates becomes a fast field update (before-save) flow.
The tool has limits that Salesforce documents, and you should read them before relying on it.
| Situation | Tool support | What to do |
|---|---|---|
| Workflow rule with field updates only | Converted to a fast field update flow | Migrate, then test |
| Workflow email alerts and outbound messages | Supported as actions in the flow | Check recipients and templates after migration |
| Record-triggered Process Builder processes | Supported | Migrate, then review the generated logic |
| Processes started by platform events or invoked by other processes | Not supported | Rebuild by hand in Flow |
| Criteria using fields on related records | Not supported | Rebuild, often with a Get Records element |
| Processes with recursion | Only partly: the record is evaluated one time | Test the recursive behavior explicitly |
| Process Builder scheduled actions | Only when a single criteria node is selected | Otherwise recreate as scheduled paths |
Migrate in the org where the original automation runs, and move the result through your normal deployment path. Salesforce notes that when a process is migrated in the same org, the new flow can pick up scheduled actions already queued by the old process; building the flow elsewhere and deploying it loses that link.
Step 3: consolidate by object
The real improvement comes from redesigning each object's automation together. Workflow Rules, Process Builder, Flows and Apex triggers all run at different points in Salesforce's order of execution, so a record-triggered flow can behave differently from the workflow rule it replaces. Gather everything that fires on, say, Opportunity, and decide how it should look in Flow as a set.
- Put same-record field updates in before-save flows, which do not need a second save of the record.
- Put actions that touch other records, send emails or call out to other systems in after-save flows.
- Use entry conditions so each flow runs only when the fields it cares about change.
- Group related logic into a small number of flows per object and trigger timing, rather than one flow per old rule.
- Set the run order explicitly and review it in Flow Trigger Explorer, which shows every record-triggered flow on an object.
- Replace hard-coded users, queues and IDs with variables, custom metadata or custom labels.
- Name and describe every flow so the next admin knows what it does and who asked for it.
Hard-coding is worth singling out. An industrial-services firm we worked with had inherited flows that fired 30 emails at once; part of the repair was restructuring its task-creation flows to use variables instead of hard-coded assignments. Migrations are the natural moment to fix that kind of problem, because you are already opening and testing the logic.
Step 4: test before you switch
Build and test in a sandbox with realistic data, not in production. Salesforce's own Trailhead guidance on this migration is blunt: do not debug flows against live data in production. For each object, write down what should happen for the scenarios the old automation covered, then prove the new flows produce the same outcome.
- Create, edit and bulk-update records, including a data load of a few hundred rows, to check limits and performance.
- Confirm emails go to the right people once, not twice from old and new automation running together.
- Check scheduled paths fire at the right time, and that items queued under the old process still complete.
- Run integrations and managed packages that write to the object, since they trigger the same flows.
- Keep the old rule inactive but in place for a release cycle, so you can compare or roll back if needed.
Switch one object at a time, starting with the one where the automation is simplest and best understood. Once a few objects are live and stable, the pattern for the harder ones, usually Opportunity, Case and Account, is much clearer. If your org also has a backlog of Flow issues or you lack the time to test properly, an automation-focused health check or a short optimization engagement is a sensible way to size the work first.
