Moving from Workflow Rules and Process Builder to Flow
Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025. Existing rules and processes keep running, and Salesforce's pages say you can still edit, activate and deactivate them, but Salesforce no longer fixes bugs in them, and new automation is meant to be built in Flow.
This guide covers seven steps for one object at a time: inventory, retire, choose tool or rebuild, design, order, test and cut over.
What end of support means, and what it does not
Salesforce's pages say that existing automation continues to run as it did before. What changed is that customer support is not available for these tools and bugs are not fixed. Salesforce tells customers to build new automation in Flow Builder.
Some guides give a date on which these tools switch off. The Salesforce pages we checked on 28 October 2026 do not say that. The likely risk is gradual: the older automation can become the part of the org that nobody is willing to change, and any problem in it stays unfixed. Limits quoted in this guide were read on 28 October 2026 and can change.
Step 1: Take an inventory before you touch anything
Work object by object, starting with the ones that drive money and forecasts: Opportunity, Account, Case, and any object that feeds billing.
For each object, list every Workflow Rule, every Process Builder process, every flow, every Apex trigger and every validation rule. In Setup, open Workflow Rules, Process Builder and Flows. Keep the list in one table:
| Object | Automation | Type | Fields it writes | Owner | Still used? | Plan |
|---|---|---|---|---|---|---|
| Opportunity | Set discount approval | Workflow Rule | Approval Status | Sales operations | Yes | Convert |
For each item, add one line on what it does and who owns it. That page is the starting point for the next admin.
Two tool limits matter while you build the list:
- Flow Trigger Explorer shows record-triggered flows for an object. Salesforce's help page does not say that it lists Apex triggers, Workflow Rules or processes, so it covers only part of the inventory.
- Where is this used? on a custom field's detail page shows where Flow and Process Builder criteria refer to that field. It does not mention Workflow Rules, and it stops at the first 2,000 entries.
Neither tool replaces reading the automation. For a field that matters, open each item that touches it. Then mark every field written by more than one automation. Those fields are the most likely to behave differently after a move, because the order in which the automations run can change.
Step 2: Retire what nobody uses
Some of what you find no longer does anything useful: rules for products you no longer sell, processes for teams that were reorganised, field updates for fields nobody reads. Ask the owner first. Then deactivate the item in a sandbox, run the three most common create and update paths for that object, and check whether an integration user, a scheduled action or a month-end job also triggers it.
A sandbox run that shows no change is a reason to retire an item, not proof that it is unused. Time-based actions and rare paths do not fire in a quick test. Deactivate in production first, and delete only after a full business cycle. Salesforce's best-practice guidance makes a related point: a migration is not one to one, so look for redundant automation and start with one object and the easiest items.
Step 3: Choose the Migrate to Flow tool or a rebuild
Salesforce provides a Migrate to Flow tool. In Setup, search for Migrate to Flow. It works on Workflow Rules and on record-triggered processes. Read Salesforce's considerations page before you start, because the list of what it cannot convert is specific:
| Area | What Salesforce says is not converted or needs manual work |
|---|---|
| Workflow Rules | Task actions, related-record fields, record types, relative date values, multiple currencies, some operators and some formula functions such as HOUR, MINUTE, SECOND and TIMENOW |
| Processes | Recursion is not fully supported. Cross-object formula references and field traversals are not supported. Custom event and custom invocable processes are not supported |
| Scheduled actions | If a process has multiple criteria selected, no scheduled actions are migrated. Each outcome needs its own scheduled-action flow |
| Some actions | Chatter posts, quick actions, submit for approval, custom notifications and surveys need manual setup after migration |
The tool behaves differently for the two sources. A Workflow Rule migration creates an inactive flow, and a Switch Activations button deactivates the rule and activates the flow in one step. A process migration has no Switch Activations: you activate the flow and then deactivate the process yourself. Salesforce changes these pages from release to release, so read the current version before you plan the work.
Use the tool when an item has none of the following. Rebuild by hand when it has any one of them:
- recursion in a process;
- multiple criteria combined with scheduled actions;
- a formula function the tool does not convert;
- another automation on the same object writing the same field.
In those cases the migrated flow would carry the same overlap into a new tool, or need heavy rework, so the tool gives you a reference at most. For every action on the manual-setup row, find the matching action in Flow Builder and test it in a sandbox.
Step 4: Decide the design before you copy the logic
A straight copy keeps the overlap and moves the confusion into a new tool. Where three automations touch the same field, decide the single outcome you want, then build one flow for it.
The order of execution matters here, because it changes when automation moves. Salesforce documents the full order for every save. These are the points that bear on this move, simplified:
- Before-save flows run first.
- Before triggers run next.
- Workflow Rules run after auto-response rules.
- Processes, and flows launched by workflow rules or processes, run in no guaranteed order.
- After-save flows run after those.
A field update made by a Workflow Rule also causes before and after update triggers to run once more. So a field update that sits in a Workflow Rule today and moves to a before-save flow will now happen before any trigger runs. Code that relied on seeing the old value first, or on running twice, can behave differently. This is a risk to test for, not a certainty.
Choose the flow type from the work:
- Before-save flow: use it for simple field updates on the same record. It updates the record that triggered it without a second save, and Salesforce notes that it has the least impact on the database.
- After-save flow: use it for related records and actions that need the saved record.
- Scheduled path: use it to replace the time-dependent actions in a Workflow Rule.
- Asynchronous path: use it for work that can wait until after the triggering update completes.
Step 5: Set the order of the flows
When several record-triggered flows run on one object, open Flow Trigger Explorer for that object. It groups flows into before save, after save, asynchronous and scheduled path, and lets you change the order within a group. Salesforce's page gives two cautions: the order inside the asynchronous group is not guaranteed, so do not build dependencies there, and pending scheduled items appear on a separate Time-Based Automations page. Our suggestion is to leave gaps in any numbering you set, such as 10, 20 and 30, so that a future flow can slot in.
Step 6: Test against the old behaviour, not only the new one
Use a sandbox that matches production. If it is months out of date, refresh it first, or you will test against a different org.
For each migrated item, create the same record in the old and the new setup and compare the field values side by side. Our suggestion is to add a bulk case, for example a Data Loader file of 200 records, because automation can behave differently when many records are saved together. Salesforce provides flow tests, where each scenario passes only if all of its assertions pass and the test rolls back by default. Since Summer '26, Salesforce also lets you convert a debug run into a test. Use them for the cases that must never regress, and keep Apex tests and validation rules in your regression run, because they react to the same saves.
Step 7: Cut over one object at a time
Deploy the new flows inactive. In one change window, activate the flow and deactivate the old rule or process, so that both do not fire on the same save. Tell the users who own the process what changed. Do not delete the old automation on the day. A deactivated rule can still be re-activated, which gives you a way back if something is wrong. Delete it after a full business cycle, for example one month-end close, has passed without a problem.
This guide does not replace testing in your own org.
Where we fit
We do not sell a migration tool. If your inventory shows overlapping automation, the Org Review shows what to retire, merge and rebuild before you move it.
The Org Review is our fixed-fee review of your Salesforce setup, from USD 3,500. It gives you a costed list of what needs fixing, what it costs to leave it and what the fix takes. You keep the findings whether or not you hire us for the work.
If you would like to talk it through, book a free twenty-minute call.
Sources
Salesforce statements in this guide were checked against these pages on 28 October 2026.
Related guides
Start with the Org Review, not a contract
A fixed fee from USD 3,500, ending in a costed fix list you own outright. Book a free twenty-minute call about your Salesforce automation.