Moving from Workflow Rules and Process Builder to Flow

Salesforce ended support for Workflow Rules and Process Builder at the end of 2025. Existing rules still run, but they get no bug fixes, and every new automation feature now ships only in Flow. If your org still depends on them, the risk grows with every release.

Here's the approach we use on client orgs.

1. Take inventory

List every active Workflow Rule, Process Builder process and Flow, grouped by object. Note what triggers each one, what it changes, and whether it sends email or calls out to another system. You'll often find duplicates and automations nobody remembers building.

2. Decide what to keep

For each item, choose one of three outcomes:

• Retire it if it's inactive in practice or duplicates something else.
• Migrate it as-is if it's simple and still needed.
• Redesign it if several rules on the same object should become one well-ordered Flow.

3. Use the Migrate to Flow tool, then clean up

Salesforce's Migrate to Flow tool in Setup converts many Workflow Rules and processes automatically. Treat its output as a first draft: rename elements, add descriptions, and combine related logic.

4. Set a clear order per object

When an object has several record-triggered Flows, use entry conditions and the Flow trigger order setting so you know exactly what runs first. Unclear ordering is the most common source of "it worked in the sandbox" bugs.

5. Add fault handling

Every Flow that updates records or calls out should have a fault path that logs the error or emails an admin. Legacy automation often failed silently. Don't carry that forward.

6. Test, switch over, watch

1. Build and test in a full or partial sandbox with realistic data.
2. Deploy the new Flows inactive, then activate them and deactivate the old rule in the same window.
3. Watch Flow error emails and key reports for a week before deleting the old automation.

Quick checklist