Workflow Rules to Flow: A Practical Migration Guide for Salesforce Admins (2026)

If you're reading this, you already know Salesforce is shutting Workflow Rules down. Spring '25 was the last release where you could create new Workflow Rules. Existing rules will keep running for a while — but Salesforce has been clear: convert them to Flow, and do it on your timeline, not theirs.

The official migration tool ("Migrate to Flow") is helpful for the easiest cases. For the messier real-world stuff — workflows with cross-object field updates, time-based actions, or outbound messages — you're going to do most of the work by hand. This guide walks through the exact playbook used by teams shipping migrations cleanly.

The TL;DR for the impatient

• Inventory first, then prioritize. Run a quick SOQL query to count active Workflow Rules per object. The 20% of objects with the most rules will represent 80% of your work.
• Use Migrate to Flow for the simple cases. It handles ~60% of typical workflows correctly out of the box.
• Build in a sandbox. Always. Never convert directly in production, even for "simple" rules.
• Test the migrated Flow against the same test data the original Workflow Rule fired on. Otherwise you won't catch silent behavior changes.
• Deactivate the old Workflow Rule before activating the new Flow. Otherwise both fire and you get duplicate updates.
• Save the migration commit somewhere. When something breaks three weeks later, you'll want to know exactly what changed.

Step 1: Inventory what you have

Open Setup → Workflow Rules. You're looking at the list. Now answer three questions for every active rule:

1. What object does it run on? (Account, Opportunity, Custom Object X, etc.)
2. What does it do? Field update, email alert, task creation, outbound message, time-based?
3. How critical is it? Will the business break if it stops firing for a day?

A spreadsheet works fine for this. Five columns: Rule Name, Object, Actions, Criticality, Migrated?. Spend an hour on it. The shape of your migration backlog suddenly becomes obvious.

If you have more than 30 Workflow Rules, also run this SOQL in Developer Console to get a programmatic export:

SELECT Id, Name, TableEnumOrId, Active, FormulaTrigger
FROM WorkflowRule
WHERE Active = true
ORDER BY TableEnumOrId, Name

Export the result to CSV. That's your master list.

Step 2: Categorize each rule by migration difficulty

Not every Workflow Rule converts cleanly. Categorize each one:

Difficulty	What it looks like	Approach
Easy	Single object, single field update, immediate (not time-based)	Run "Migrate to Flow" tool. Verify and ship.
Medium	Single object, multiple actions, or one cross-object field update	Migrate to Flow as a starting point, then hand-edit the result. Common to need to add a Get Records or Update Records element.
Hard	Time-based actions, outbound messages, or workflows that fire from custom Apex	Build the Flow from scratch. The migration tool can't translate these reliably.

The Easy/Medium split usually comes out 60/30/10 for a typical org. The 10% Hard cases will eat 50%+ of your time — plan accordingly.

Step 3: Use the official "Migrate to Flow" tool (for Easy/Medium cases)

Setup → Workflow Rules → Migrate to Flow. Pick a rule. Salesforce builds you a draft Flow. Review what it generated. Do not click Activate yet.

Common things the migration tool gets wrong:

• Trigger type. The migration tool defaults to "After Save" record-triggered Flow. For workflows that update fields on the same record, you almost always want "Before Save" instead — it's much faster and avoids extra DML.
• Entry conditions. The original Workflow Rule's "Rule Criteria" gets copied as the Flow start element's filter. But subtle differences in operator handling (especially around picklists and ISBLANK) can cause silent behavior changes. Read the entry conditions carefully.
• Field update sequencing. If your Workflow Rule did three field updates, the migrated Flow does them as three separate Update Records elements. That works, but it's three DML operations instead of one. Consolidate them into a single "Set Field Values" action on a Before Save Flow.

Step 4: Hand-build the Hard cases

For time-based actions, outbound messages, or workflows fired from Apex, the migration tool either fails or produces something you'll need to rewrite anyway. Here's how to think about each:

Time-based actions → Scheduled Path on a Record-Triggered Flow

The original "5 days after the close date" workflow becomes a Scheduled Path on the Flow with a 5-day delay relative to the close date. Two gotchas:

• Scheduled Paths only fire if the entry criteria are still true when the path runs. If the record changed, the action might not fire — which is usually what you want, but verify.
• The Time-Based Workflow Queue is being deprecated. Existing time-based actions will continue to fire, but you can't create new ones via Workflow Rules anymore.

Outbound messages → Apex callouts in the Flow

Flow doesn't have a native Outbound Message action. You have two choices:

1. Keep the existing Outbound Message active, and have the new Flow fire it via a Send Outbound Message invocable Apex (write a small wrapper). This is the path of least resistance.
2. Rewrite as an HTTP callout using a Named Credential. More work, but Outbound Messages have a long list of limitations that callouts don't.

Workflows triggered from custom Apex → just leave them

If you have Apex code that calls workflow.fire or relies on a Workflow Rule firing as a side effect, that's a much bigger migration project. The Flow won't fire from the same trigger point. You'll need to refactor the Apex to call the Flow directly. This is a custom-development task, not a migration task — scope it separately.

Step 5: Test like you mean it

The biggest source of post-migration bugs: the new Flow does almost the same thing as the old Workflow Rule, but not exactly. To catch this:

1. Build a test data set in your sandbox that exercises every entry condition the original Workflow Rule had. If the rule fired on "Stage = Closed Won AND Amount > 50000," create three records: one that satisfies both, one that satisfies only Stage, one that satisfies only Amount. Verify only the first triggers the Flow.
2. Compare side-by-side. Insert/update each test record once with only the Workflow Rule active, capture the after state. Then deactivate the Workflow Rule, activate the Flow, and repeat. The after states should be identical. If they're not, you have a bug.
3. Don't skip negative cases. Test that the Flow does not fire when entry conditions aren't met. A common migration bug is the new Flow firing too aggressively because the entry criteria got loosened.

Step 6: Deploy carefully

For production deployment, do these steps in this exact order. Skipping or reordering causes bugs that are very hard to diagnose:

1. Deploy the Flow to production in inactive state. (Activate it once it lands — don't deploy as already-active.)
2. Deactivate the old Workflow Rule in production.
3. Activate the new Flow in production.
4. Watch the next batch of records that should trigger it. Confirm the right field updates happen.
5. Wait 24 hours. If nothing breaks, delete the old (deactivated) Workflow Rule.

The "wait 24 hours" step matters. Time-based workflow actions can be queued days in advance. If you delete the rule too aggressively, queued actions silently disappear.

Common gotchas (from real migrations)

• Recursive triggers. If the Workflow Rule updates a field that itself triggers the same rule (or another rule), Salesforce had built-in protection against infinite loops. Flow handles recursion differently — you may suddenly hit the "max stack depth" governor limit. Use Before Save flows to consolidate updates into a single transaction.
• Field-level security. The integration user that runs the Flow needs read+edit access to every field the Flow touches. Workflow Rules ran as system context and bypassed FLS; record-triggered Flows (by default) run in the running user's context. Add the integration user to a permission set that grants the field access, or set the Flow to run in System Mode.
• Process Builder calling Workflow Rules. If you have Process Builder processes that depend on a Workflow Rule firing, those processes will silently stop working when you deactivate the rule. Migrate the Process Builder logic at the same time.
• Cross-object field updates with formula references. The migration tool sometimes drops cross-object formula evaluation. Double-check any field update that references a parent or child object's field via dot notation.

How long will this take?

For a typical mid-market org with 30–50 active Workflow Rules:

• Easy cases (60% of rules): 15–30 minutes each via the migration tool. ~10 hours total.
• Medium cases (30% of rules): 1–2 hours each. ~20 hours total.
• Hard cases (10% of rules): 4–8 hours each. ~30 hours total.
• Plus testing + deployment ceremony: Add 25–40% on top.

Realistic total: 2–3 weeks of focused admin time for an org with 50 rules. Plan accordingly.

Where SF Agent fits in

SF Agent doesn't replace the official Migrate to Flow tool — that's the right starting point for the Easy/Medium cases. Where SF Agent helps is:

• Building the Hard cases from scratch. Describe the Flow in plain English ("when an Opportunity is closed-won and Amount is over 50000, send an email to the regional manager and create a follow-up task for the AE"). SF Agent generates the Flow, with proper entry criteria and Update Records elements, ready for you to review and deploy.
• Generating the test data setup. "Create three Account records: one that satisfies condition A and B, one that satisfies only A, one that satisfies neither." SF Agent generates the test setup as Apex test classes you can run in the sandbox.
• The before/after comparison. Run the same prompt against your sandbox before and after deactivating the old Workflow Rule. SF Agent's run history gives you a side-by-side diff of the deployed metadata.

If you want to try this on one of your real Workflow Rules, you can start a free trial — connect a sandbox, paste a description of the rule, and SF Agent will generate the Flow for you to review.

Closing thought

Workflow-Rule-to-Flow migrations are tedious. They're also one of the highest-leverage technical debt cleanups your org can do this year. Every rule you migrate cleanly is one less thing to worry about when Salesforce eventually pulls the plug.

Take it one rule at a time. Test each one twice. And don't trust the migration tool's defaults blindly — every org has its own quirks that only show up when you compare the before-and-after behavior on real data.

Good luck. You've got this.