Workflow rules still execute, but Salesforce ended support for them on 31 December 2025 — no bug fixes, no further investment. The payoff is more than compliance: a same-record field update in a workflow rule pushes the record through a second save with every update trigger firing again, while a before-save flow sets the same field with no second save at all. Use the Migrate to Flow tool for the mechanical conversion, run both in parallel against a shadow field to prove equivalence, then retire the rule.
The performance win is in the order of execution, not the tool
Understand this before you touch anything, because it determines which flow type each rule should become.
When a workflow rule updates a field on the record that triggered it, the platform does not simply set the value. Per the order of execution documentation, it “updates the record again,” runs system validations again, and “executes before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time).” Your whole trigger stack runs twice for one user save.
A before-save record-triggered flow runs at step 3 — before the before triggers, before validation rules, before the record is written to the database. Setting a field there costs no extra DML statement and no second pass through the save. On an object with heavy trigger logic that difference is not marginal. It is the single biggest reason to migrate rather than a compliance box.
The corollary: a rule that updates a different record gets no such win. That becomes an after-save flow with an Update Records element — a separate DML statement, the same cost as before.
What each workflow action becomes
| Workflow action | Flow equivalent | What changes |
|---|---|---|
| Field update, same record | Before-save flow (Fast Field Updates) | No second save cycle. The real win. |
| Field update, related record | After-save flow, Update Records | Nothing — still a separate DML statement |
| Email alert | After-save flow, Send Email Alert action | Reuses the existing email alert, template and recipients intact |
| Task creation | After-save flow, Create Records on Task | You now set every field explicitly, including Owner and Due Date |
| Outbound message | HTTP Callout on an asynchronous path, or Apex | No like-for-like replacement. Different payload, different auth, different retry behaviour. |
| Time-dependent action | Scheduled path on the record-triggered flow | Re-evaluation semantics differ — see below |
Email alerts survive intact. A flow can invoke an existing email alert instead of rebuilding it as a Send Email element. This is the cheapest row in the table and the one people needlessly redo — the alert already holds the template, the recipients, and the from-address, all of which you would otherwise re-specify and get subtly wrong.
Outbound messages have no equivalent. An outbound message is a SOAP notification with a Salesforce-defined envelope and a session Id, fired by the platform with its own retry queue. Nothing in Flow reproduces that. You replace it with an HTTP Callout on an asynchronous path: a record-triggered flow cannot call out synchronously, because the save is uncommitted DML, or with Apex, and either way the receiving system changes. Scope outbound messages as integration work, not migration work.
Using the Migrate to Flow tool
Find it at Setup → Migrate to Flow. It converts workflow rules and record-triggered processes, and when a rule contains only field updates it produces a Fast Field Update. The before-save flow you want, without you having to know that was the right answer.
What it does not handle, per Salesforce’s Migrate to Flow Tool Considerations:
- Criteria referencing a field on a related object. Field traversals are not supported
- Criteria using custom metadata types
- For processes: custom event and custom invocable types
- Recursion. A migrated process with recursion evaluates the record only once
- Scheduled actions, unless you select the single criteria they belong to. Select multiple criteria and none migrate. Quietly
That last one is the trap: the tool reports success and the time-based half of your automation is simply absent. Check the generated flow for scheduled paths before trusting it.
Treat the output as a first draft that gets the tedious parts right. The tool will not consolidate, will not name things the way your team does, and will not tell you the rule was redundant to begin with.
The cutover, in order
- Inventory properly. The setup list is not enough.
sf project retrieve start -m Workflowgives you one file per object holding every rule, action, and field update. Greppable and diffable in a way the UI is not. - Delete before you migrate. In most orgs a meaningful share of rules are inactive, superseded by a validation rule, or stamping a field nobody reads. Migrating a dead rule just converts one maintenance problem into another.
- Migrate one rule at a time and leave the resulting flow deactivated.
- Read the generated entry conditions carefully. This is where equivalence is usually lost. See below.
- Point the flow at a shadow field. Clone the target field as
Status_Flow__cand have the flow write there while the workflow rule keeps writing the real field. - Run both for a full business cycle — a month for monthly patterns, a quarter if it touches renewals.
- Compare. Report on records where the shadow field does not equal the real field. An empty report over a full cycle, across every record type and profile that touches the object, is your equivalence proof. Anything else is an opinion.
- Cut over: deactivate the rule, repoint the flow at the real field, activate. Delete the rule after one more cycle. A deactivated rule left in place is what confuses the next person.
The shadow field costs you a field and a report. It is the only step here that produces evidence rather than confidence.
The three places equivalence quietly breaks
Re-evaluation semantics
A rule set to “created, and any time it’s edited to subsequently meet criteria” fires only on the transition into the criteria. One set to “created, and every time it’s edited” fires on every save while the criteria hold. The difference is invisible until a user edits a record twice.
In a flow, entry conditions plus the option to run only when a record is updated to meet the condition requirements gives you the first behaviour. Leave it off and you get the second. Check which one the rule used before assuming the generated flow matched it.
Re-evaluate workflow rules after field change
Workflow field updates carry a checkbox that re-runs workflow rules on the updated record, producing intentional cascades. Flow has no direct equivalent, and reproducing one means a flow that updates a record and relies on its own re-entry, which is how you write an infinite loop. Usually that is good news: an implicit cascade is better replaced by explicit logic in one flow.
Time triggers versus scheduled paths
Workflow time triggers drop out of the queue when the record stops meeting the criteria. Scheduled paths behave differently, and you control it: the path can re-check entry conditions when it runs rather than assuming they still hold. Set that deliberately. A reminder email firing after the case closed is a visible failure.
One flow per rule, or one flow per object?
Migrate one-to-one, consolidate afterwards. The reasoning is that verification is the expensive part: one flow per rule maps directly to the thing you are proving equivalent, so a shadow-field mismatch points at exactly one flow.
The cost is real. Several record-triggered flows on one object run in an order you do not control, so any rule whose outcome depends on another having already run must be consolidated rather than migrated in isolation. Once everything is migrated and verified, merge into one before-save and one after-save flow per object, with explicit ordering, as a separate change.
Frequently asked
Do workflow rules still run?
Yes. Salesforce’s end-of-support notice states that after 31 December 2025 workflow rules and Process Builder may continue to execute existing automation, but support is not available and bugs will not be fixed. Existing rules keep working. That is not the same as being safe to depend on.
Can I still create a new workflow rule?
Don’t, whatever the UI still permits. Every new rule is work you will do twice.
Will the migrated flow run as the same user?
Not necessarily as you expect. Record-triggered flows default to system context without sharing, so a migrated automation can update records the triggering user cannot see. The workflow rule often did the same, but verify rather than assume, particularly where it writes to a related object.
Should I migrate Process Builder at the same time?
Yes, object by object. Processes and workflow rules on one object interact through the save order, so migrating one and leaving the other leaves you reasoning about a hybrid that will not exist for long.
How do I know I have not missed a rule?
Retrieve the Workflow metadata again after cutover and diff it against your inventory. The setup UI groups rules by object, and it is easy to overlook an object nobody thinks of as automated: Task, Event, and User are the usual suspects.
Reference: Triggers and Order of Execution, Salesforce Apex Developer Guide. Tool behaviour and support status per “Move Processes and Workflows to Flow Builder with the Migrate to Flow Tool”, “Migrate to Flow Tool Considerations”, and “Salesforce Workflow Rules & Process Builder End of Support”, Salesforce Help.
