Workflow Rule To Flow Migration

Workflow Rule to Flow Migration

Use this skill when orgs still have active Workflow Rules that must migrate to record-triggered Flows before the December 31 2025 end-of-support deadline. New Workflow Rule creation was blocked in Spring '25; existing rules continue to execute but receive no bug fixes. This skill is distinct from process-builder-to-flow-migration — Workflow Rules and Process Builder share the same retirement timeline but require different migration approaches.

Before Starting

Gather this context before working on anything in this domain:

• Export all Workflow Rules per object via Setup > Process Automation > Workflow Rules or query WorkflowRule via Tooling API
• Identify action types per rule: field updates, email alerts, tasks, outbound messages, time-based actions
• Any rule using ISCHANGED(), ISNEW(), global variables, record-type-based criteria, or related-record field updates requires manual rebuild — the Migrate to Flow tool cannot handle these
• Confirm that Outbound Message definitions exist in Setup before attempting to reference them as Flow Core Actions

Core Concepts

What the Migrate to Flow Tool Handles

Setup > Migrate to Flow converts Workflow Rules to INACTIVE record-triggered flows for review. The tool converts:

• Field updates → Update Records or Assignment elements
• Email alerts → Send Email Action elements
• Outbound messages → Outbound Message Core Action elements (definition must pre-exist)

The tool does NOT handle:

• Task creation → must be rebuilt as Create Records elements
• ISCHANGED() / ISNEW() criteria → rebuild with {!$Record__Prior.FieldName} comparisons
• Global variables in criteria → no equivalent in Flow
• Record-type-based criteria → rebuild with explicit Decision conditions
• Related-record field updates → rebuild with Get Records + Update Records

Outbound Message Migration

Workflow Rules can invoke Outbound Messages (SOAP callouts to external endpoints). In Flow, outbound messages are available as Core Actions — but the Outbound Message definition must already exist in Setup > Outbound Messages before the Flow can reference it. The tool generates the action reference; it does not create the definition.

If the receiving endpoint expects the original Workflow Rule SOAP schema, verify that the Flow-generated outbound message produces the same WSDL payload structure. Schema differences can break integrations silently.

Time-Based Action Replacement

Workflow time-based actions (e.g., "send email 5 days after close date") are replaced using Scheduled Paths on record-triggered flows. Set the Scheduled Path's time source field to the same date/time field used in the workflow time trigger. When the original Workflow Rule is deactivated, pending time-based actions in the queue are cancelled — they do not transfer to the Flow.

Common Patterns

Tool-Eligible Field Update Migration

When to use: Workflow Rule updates fields on the same record, uses no ISCHANGED/ISNEW criteria, no tasks, no global variables.

How it works:

1. Setup > Migrate to Flow > select rule > Convert
2. Review the generated inactive flow in Flow Builder: verify Decision conditions match original rule criteria
3. Add Fault Paths to Update Records elements (tool never generates fault paths)
4. Set Flow Trigger Explorer priority matching intended execution order
5. Test with 200+ records in sandbox; activate and deactivate source Workflow Rule simultaneously

Time-Based Action to Scheduled Path

When to use: Workflow Rule has time-based actions (e.g., send follow-up email N days after OpportunityCloseDate).

How it works: In the record-triggered flow, add a Scheduled Path:

• Set path to run "N Days After" the relevant date field
• Move all actions that previously ran as time-based into this Scheduled Path
• Note: pending in-flight actions from the original Workflow Rule will be cancelled on deactivation — plan cutover timing accordingly

Manual Rebuild for ISCHANGED Criteria

When to use: Workflow Rule uses ISCHANGED(FieldName) or ISNEW() in entry criteria.

How it works: In a new record-triggered flow's Decision element:

• ISCHANGED(FieldName) → {!$Record.FieldName} != {!$Record__Prior.FieldName} (for after-save) or "Is Changed" condition (for entry criteria)
• ISNEW() → trigger set to "Only when a record is created" OR Decision: {!$Record__Prior.Id} Is Null

Decision Guidance

Recommended Workflow

1. Inventory and triage. Query SELECT Id, Name, TableEnumOrId, Active FROM WorkflowRule via Tooling API or SOQL; note action types for each rule. Mark any rule with ISCHANGED/ISNEW criteria, task actions, or global variables as manual-rebuild. Confirm Outbound Message definitions exist in Setup before running the tool.
2. Run Migrate to Flow on eligible rules. Setup > Migrate to Flow > select rule > Convert. Tool creates INACTIVE flow — review in Flow Builder.
3. Rebuild unsupported elements. Add Create Records for tasks, Scheduled Paths for time-based actions, rebuild ISCHANGED criteria with $Record__Prior.
4. Add Fault Paths. Add fault connectors to all Update Records and Create Records elements — the tool never generates them.
5. Assign Flow Trigger Explorer priorities. Open Flow Trigger Explorer for the object; assign priority integers preserving intended order relative to other flows.
6. Test, activate, and cut over. Load 200+ records in sandbox; verify field values, email alerts, and time-based path scheduling. Activate the Flow and deactivate the Workflow Rule simultaneously — never run both active on the same object.

Review Checklist

• All Workflow Rules inventoried; unsupported criteria/actions identified before running tool
• Outbound Message definitions confirmed existing before running tool
• ISCHANGED()/ISNEW() criteria rebuilt with $Record__Prior comparisons
• Task creation rebuilt as Create Records elements
• Scheduled Paths added for all time-based actions
• Fault Paths added to all DML elements
• Flow Trigger Explorer priorities assigned
• Workflow Rule deactivated the same moment the Flow is activated
• Pending time-based actions in flight accounted for in cutover plan

Salesforce-Specific Gotchas

1. Pending time-based workflow actions are cancelled on deactivation — Like Process Builder scheduled actions, pending time-based workflow queue entries are silently cancelled when the Workflow Rule is deactivated. No transfer occurs. Audit ProcessInstanceStep and AsyncApexJob for in-flight actions before cutting over.
2. Outbound message SOAP schema may differ from Flow-generated payload — If the receiving endpoint validates the incoming SOAP envelope against the original Workflow-generated WSDL, verify that the Flow Core Action sends the same structure. Schema differences can silently break integrations without error in Salesforce.
3. ISCHANGED() and ISNEW() silently dropped or mis-mapped by the tool — The Migrate to Flow tool does not warn about ISCHANGED/ISNEW criteria and may omit them or fire unconditionally. Always audit these criteria before using the tool.

Output Artifacts

Related Skills

• flow/process-builder-to-flow-migration — companion skill for Process Builder retirement
• flow/record-triggered-flow-patterns — canonical patterns for the destination flow type
• flow/fault-handling — add fault paths to migrated flows
• Decision tree: standards/decision-trees/automation-selection.md