Migrating Workflow Rules and Process Builder to Flow
5 minutes
5 Questions
Salesforce is retiring Workflow Rules and Process Builder in favor of Flow Builder as the single declarative automation tool. For Platform Administrator II candidates, understanding the migration path is essential. Salesforce stopped allowing creation of new Workflow Rules and Processes (Winter '23), and existing ones are planned for end of support, so admins must move legacy automation into Flow. Salesforce provides the Migrate to Flow tool (Setup > Migrate to Flow). It lists active Workflow Rules and Process Builder processes and converts them into record-triggered flows. Workflow Rule migration supports field updates, email alerts, outbound messages, and tasks, including time-dependent actions, which become scheduled paths. Process Builder migration supports many action types such as record updates, record creation, email alerts, and invoking other processes or flows, though some features (certain formula functions, custom notifications, Chatter posts in some cases) may require manual rework. After conversion, the tool creates the flow in an inactive state; the admin reviews the logic, tests in a sandbox, activates the flow, and then deactivates the original rule or process to avoid duplicate actions. Best practices include: inventory and document all automation per object before migrating; consolidate multiple rules into one or a few record-triggered flows per object to simplify order of execution and improve performance; use Fast Field Updates (before-save) for same-record field changes and Actions and Related Records (after-save) for related records, emails, or external calls; leverage entry conditions and 'only when a record is updated to meet condition requirements' to replicate ISCHANGED behavior; add fault paths and use the debug tool; and set Flow Trigger Explorer or trigger order to control sequencing. Migration also changes order of execution, since before-save flows run earlier than Workflow Rules did, so recursion and validation interactions must be retested. Communicating changes, using change sets or DevOps Center for deployment, and monitoring with Flow error emails complete a successful migration.
Migrating Workflow Rules and Process Builder to Flow: A Complete Guide for the Salesforce Advanced Administrator Exam
Why This Topic Matters
Salesforce has officially retired Workflow Rules and Process Builder as tools for building new automation. Since Winter '23, you can no longer create new Workflow Rules, and Process Builder creation was blocked shortly after. Salesforce has stated that Flow is the single, go-forward automation tool on the platform. For the Advanced Administrator exam, this means you are expected to understand why the migration is happening, how to perform it using the Migrate to Flow tool, and how to design equivalent Flow logic when the tool cannot handle a particular use case. Questions in the Advanced Process Automation section frequently present a legacy automation scenario and ask you to choose the correct migration approach or the correct Flow type to replace it.
Beyond the exam, this knowledge is critical in real orgs. Legacy automations that sit alongside Flows create unpredictable execution order, duplicate logic, and performance problems. An Advanced Administrator is expected to consolidate automation into well-designed Flows that follow Salesforce best practices.
What It Is
Migrating Workflow Rules and Process Builder to Flow is the process of converting legacy declarative automation into Flow Builder automation, typically Record-Triggered Flows. Salesforce provides a native tool called Migrate to Flow (found in Setup under Process Automation) that automatically converts supported Workflow Rules and Process Builder processes into Flows. The tool analyzes the legacy automation, generates an equivalent Flow, and lets you test it before deactivating the original.
Key concepts you must know:
Workflow Rules evaluate a single object when a record is created or edited, and can perform four action types: Field Update, Email Alert, Task creation, and Outbound Message. They can also have time-dependent actions that execute later based on a date field.
Process Builder is more powerful than Workflow Rules. It supports multiple criteria nodes, can update related records (including child records), launch Flows, post to Chatter, submit records for approval, call Apex, and create records. It also supports scheduled actions.
Flow Builder replaces both with Record-Triggered Flows (which run when a record is created, updated, or deleted), Schedule-Triggered Flows, Platform Event-Triggered Flows, Screen Flows, and Autolaunched Flows. Record-Triggered Flows have two main variants that matter for migration: Fast Field Updates (Before Save) and Actions and Related Records (After Save).
How It Works
1. The Migrate to Flow Tool
Navigate to Setup, search for Migrate to Flow, and you will see a list of your Workflow Rules and Process Builder processes. The tool indicates which ones are supported for automatic migration. When you select one and click Migrate to Flow, Salesforce creates a new Flow (in draft/inactive status) that replicates the logic. You then review the Flow, test it in a sandbox, activate the Flow, and deactivate the original Workflow Rule or Process.
The tool handles most common patterns, but there are limitations. For Workflow Rules, it supports field updates, email alerts, tasks, and outbound messages, and it also handles time-dependent actions by creating scheduled paths. For Process Builder, the tool supports many but not all action types. Processes that invoke Apex, use certain formula functions, or have complex configurations may require manual rebuilding.
2. Choosing the Right Flow Type
A core exam skill is matching the legacy automation to the correct Flow design:
A Workflow Rule that only updates fields on the same record should become a Before-Save (Fast Field Updates) Record-Triggered Flow. Before-save Flows are far more efficient because they do not require an additional DML operation; the field changes are applied before the record is committed to the database.
A Workflow Rule or Process that sends emails, creates tasks, updates related records, or posts to Chatter must become an After-Save (Actions and Related Records) Record-Triggered Flow, because those actions require the record to already exist in the database.
Time-dependent Workflow actions and Process Builder scheduled actions become Scheduled Paths within a Record-Triggered Flow. A Scheduled Path lets you specify an offset (for example, 7 days after Close Date) and the actions run at that time.
Process Builder evaluation criteria of "only when a record is created" or "when a record is created or edited to meet criteria" map to Flow trigger configuration: the entry conditions, the "when a record is created", "when a record is updated", or "when a record is created or updated" options, and the critical checkbox "Only when a record is updated to meet the condition requirements", which replicates the ISCHANGED-style behavior that prevents the Flow from firing on every edit.
3. Consolidation Best Practice
Salesforce recommends one Record-Triggered Flow per object per trigger type (one before-save, one after-save) rather than many small Flows. When migrating multiple Workflow Rules on the same object, you should consider consolidating them into a single Flow with Decision elements that branch to the appropriate logic. This gives you control over the order of execution, which was never possible with multiple Workflow Rules firing in an undefined order. Trigger Order (a field on the Flow's trigger settings) also allows you to explicitly sequence multiple Flows on the same object if consolidation is not practical.
4. Execution Order Considerations
During a migration, you may temporarily have legacy automation and Flows running on the same object. Know the order of execution: before-save Flows run before Apex triggers and before validation rules are evaluated for the second time, after-save Flows run after Apex triggers, and Workflow Rules and Process Builder run after after-save Flows. If a Workflow Rule field update fires, it can cause before-save and after-save Flows and triggers to run again. This is why Salesforce strongly discourages mixing automation types on the same object and why deactivating the legacy automation promptly after migration is important.
5. Testing and Deactivation
Always migrate in a sandbox first. Use Flow's Debug feature to test with sample records. Compare outcomes between the legacy automation and the new Flow. Once confident, activate the Flow and deactivate (not delete) the original Workflow Rule or Process so you can roll back if needed. Only delete the legacy automation after a reasonable period of validation.
6. Common Manual Conversion Scenarios
Some patterns need manual attention:
Workflow Rule formulas using functions that behave differently in Flow may need adjustment. The ISCHANGED and PRIORVALUE functions are available in Flow formulas and in Flow entry conditions through the record prior value variable ($Record__Prior).
Process Builder processes that call Apex must be rebuilt using invocable Apex actions in Flow (the Apex class must have an @InvocableMethod).
Processes that launch another Flow become Subflow elements.
Processes that use the "Submit for Approval" action use the Submit for Approval core action in Flow.
Outbound Messages are supported in Flow as a core action for Record-Triggered Flows.
How to Answer Exam Questions on This Topic
Exam questions typically fall into a few patterns. First, scenario questions that describe an existing Workflow Rule and ask which Flow type should replace it. Second, questions about the Migrate to Flow tool and its limitations. Third, questions about best practices such as consolidation and execution order. Fourth, questions about handling time-based automation.
When reading a question, identify three things: what object and trigger event is involved, what actions the automation performs, and whether there is any time-based or related-record component. Those three facts almost always determine the correct answer.
Exam Tips: Answering Questions on Migrating Workflow Rules and Process Builder to Flow
Tip 1: Same-record field update means before-save. If the scenario describes a Workflow Rule that updates a field on the triggering record and nothing else, the answer is a Before-Save (Fast Field Updates) Record-Triggered Flow. This is the single most tested concept. Do not pick after-save unless other actions are involved.
Tip 2: Emails, tasks, related records, Chatter, or approvals mean after-save. Any action that requires the record ID or touches other records requires an After-Save (Actions and Related Records) Flow.
Tip 3: Time-dependent actions become Scheduled Paths. If the question mentions sending a reminder X days before or after a date, the correct Flow answer is a Record-Triggered Flow with a Scheduled Path. Do not choose a Schedule-Triggered Flow unless the scenario describes a batch process that runs for all records at a set time regardless of a record change.
Tip 4: Know what the Migrate to Flow tool can and cannot do. It supports Workflow Rules with field updates, email alerts, tasks, outbound messages, and time-dependent actions, and it supports many Process Builder processes. Processes with Apex actions or unusual configurations may need manual rebuilding. If a question says the tool failed or is unavailable for a process, the answer involves manually building the Flow.
Tip 5: Deactivate, don't delete, after migration. Questions about the migration procedure expect you to test in a sandbox, activate the Flow, and then deactivate the legacy automation. Deleting first or running both indefinitely are wrong answers.
Tip 6: Consolidate when possible. If a question describes several Workflow Rules on the same object and asks for the best practice, favor the answer that consolidates them into a single Record-Triggered Flow using Decision elements, or that uses Trigger Order to control sequencing.
Tip 7: Recognize execution-order traps. If a scenario describes unexpected behavior where a Flow runs twice or a field value is overwritten, the likely cause is a legacy Workflow Rule or Process still active on the same object, causing recursion. The fix is to complete the migration and deactivate the legacy automation.
Tip 8: Entry criteria replicate Process Builder's "edited to meet criteria" option. If a question asks how to ensure the Flow only fires when a record changes to meet criteria rather than on every edit, the answer is the "Only when a record is updated to meet the condition requirements" setting in the trigger configuration.
Tip 9: Eliminate answers that suggest building new Workflow Rules or Processes. Since these tools are retired for new automation, any answer that proposes creating a new Workflow Rule or Process Builder is incorrect. The exam is testing whether you know Flow is the only supported path forward.
Tip 10: Watch for keywords. "Efficient" or "performance" usually points to before-save Flows. "Related records" or "child records" points to after-save. "Days after" or "reminder" points to Scheduled Paths. "Apex" points to invocable actions and manual rebuild. "Order" points to Trigger Order or consolidation.
Summary
Migrating from Workflow Rules and Process Builder to Flow is both a practical necessity and a well-represented exam topic. Master the Migrate to Flow tool, understand the distinction between before-save and after-save Record-Triggered Flows, know how Scheduled Paths replace time-dependent actions, and internalize the best practices of consolidation, sandbox testing, and prompt deactivation of legacy automation. With these fundamentals, you will be well prepared to handle any migration scenario the Advanced Administrator exam presents.
Salesforce has officially retired Workflow Rules and Process Builder as tools for building new automation. Since Winter '23, you can no longer create new Workflow Rules, and Process Builder creation was blocked shortly after. Salesforce has stated that Flow is the single, go-forward automation tool on the platform. For the Advanced Administrator exam, this means you are expected to understand why the migration is happening, how to perform it using the Migrate to Flow tool, and how to design equivalent Flow logic when the tool cannot handle a particular use case. Questions in the Advanced Process Automation section frequently present a legacy automation scenario and ask you to choose the correct migration approach or the correct Flow type to replace it.
Beyond the exam, this knowledge is critical in real orgs. Legacy automations that sit alongside Flows create unpredictable execution order, duplicate logic, and performance problems. An Advanced Administrator is expected to consolidate automation into well-designed Flows that follow Salesforce best practices.
What It Is
Migrating Workflow Rules and Process Builder to Flow is the process of converting legacy declarative automation into Flow Builder automation, typically Record-Triggered Flows. Salesforce provides a native tool called Migrate to Flow (found in Setup under Process Automation) that automatically converts supported Workflow Rules and Process Builder processes into Flows. The tool analyzes the legacy automation, generates an equivalent Flow, and lets you test it before deactivating the original.
Key concepts you must know:
Workflow Rules evaluate a single object when a record is created or edited, and can perform four action types: Field Update, Email Alert, Task creation, and Outbound Message. They can also have time-dependent actions that execute later based on a date field.
Process Builder is more powerful than Workflow Rules. It supports multiple criteria nodes, can update related records (including child records), launch Flows, post to Chatter, submit records for approval, call Apex, and create records. It also supports scheduled actions.
Flow Builder replaces both with Record-Triggered Flows (which run when a record is created, updated, or deleted), Schedule-Triggered Flows, Platform Event-Triggered Flows, Screen Flows, and Autolaunched Flows. Record-Triggered Flows have two main variants that matter for migration: Fast Field Updates (Before Save) and Actions and Related Records (After Save).
How It Works
1. The Migrate to Flow Tool
Navigate to Setup, search for Migrate to Flow, and you will see a list of your Workflow Rules and Process Builder processes. The tool indicates which ones are supported for automatic migration. When you select one and click Migrate to Flow, Salesforce creates a new Flow (in draft/inactive status) that replicates the logic. You then review the Flow, test it in a sandbox, activate the Flow, and deactivate the original Workflow Rule or Process.
The tool handles most common patterns, but there are limitations. For Workflow Rules, it supports field updates, email alerts, tasks, and outbound messages, and it also handles time-dependent actions by creating scheduled paths. For Process Builder, the tool supports many but not all action types. Processes that invoke Apex, use certain formula functions, or have complex configurations may require manual rebuilding.
2. Choosing the Right Flow Type
A core exam skill is matching the legacy automation to the correct Flow design:
A Workflow Rule that only updates fields on the same record should become a Before-Save (Fast Field Updates) Record-Triggered Flow. Before-save Flows are far more efficient because they do not require an additional DML operation; the field changes are applied before the record is committed to the database.
A Workflow Rule or Process that sends emails, creates tasks, updates related records, or posts to Chatter must become an After-Save (Actions and Related Records) Record-Triggered Flow, because those actions require the record to already exist in the database.
Time-dependent Workflow actions and Process Builder scheduled actions become Scheduled Paths within a Record-Triggered Flow. A Scheduled Path lets you specify an offset (for example, 7 days after Close Date) and the actions run at that time.
Process Builder evaluation criteria of "only when a record is created" or "when a record is created or edited to meet criteria" map to Flow trigger configuration: the entry conditions, the "when a record is created", "when a record is updated", or "when a record is created or updated" options, and the critical checkbox "Only when a record is updated to meet the condition requirements", which replicates the ISCHANGED-style behavior that prevents the Flow from firing on every edit.
3. Consolidation Best Practice
Salesforce recommends one Record-Triggered Flow per object per trigger type (one before-save, one after-save) rather than many small Flows. When migrating multiple Workflow Rules on the same object, you should consider consolidating them into a single Flow with Decision elements that branch to the appropriate logic. This gives you control over the order of execution, which was never possible with multiple Workflow Rules firing in an undefined order. Trigger Order (a field on the Flow's trigger settings) also allows you to explicitly sequence multiple Flows on the same object if consolidation is not practical.
4. Execution Order Considerations
During a migration, you may temporarily have legacy automation and Flows running on the same object. Know the order of execution: before-save Flows run before Apex triggers and before validation rules are evaluated for the second time, after-save Flows run after Apex triggers, and Workflow Rules and Process Builder run after after-save Flows. If a Workflow Rule field update fires, it can cause before-save and after-save Flows and triggers to run again. This is why Salesforce strongly discourages mixing automation types on the same object and why deactivating the legacy automation promptly after migration is important.
5. Testing and Deactivation
Always migrate in a sandbox first. Use Flow's Debug feature to test with sample records. Compare outcomes between the legacy automation and the new Flow. Once confident, activate the Flow and deactivate (not delete) the original Workflow Rule or Process so you can roll back if needed. Only delete the legacy automation after a reasonable period of validation.
6. Common Manual Conversion Scenarios
Some patterns need manual attention:
Workflow Rule formulas using functions that behave differently in Flow may need adjustment. The ISCHANGED and PRIORVALUE functions are available in Flow formulas and in Flow entry conditions through the record prior value variable ($Record__Prior).
Process Builder processes that call Apex must be rebuilt using invocable Apex actions in Flow (the Apex class must have an @InvocableMethod).
Processes that launch another Flow become Subflow elements.
Processes that use the "Submit for Approval" action use the Submit for Approval core action in Flow.
Outbound Messages are supported in Flow as a core action for Record-Triggered Flows.
How to Answer Exam Questions on This Topic
Exam questions typically fall into a few patterns. First, scenario questions that describe an existing Workflow Rule and ask which Flow type should replace it. Second, questions about the Migrate to Flow tool and its limitations. Third, questions about best practices such as consolidation and execution order. Fourth, questions about handling time-based automation.
When reading a question, identify three things: what object and trigger event is involved, what actions the automation performs, and whether there is any time-based or related-record component. Those three facts almost always determine the correct answer.
Exam Tips: Answering Questions on Migrating Workflow Rules and Process Builder to Flow
Tip 1: Same-record field update means before-save. If the scenario describes a Workflow Rule that updates a field on the triggering record and nothing else, the answer is a Before-Save (Fast Field Updates) Record-Triggered Flow. This is the single most tested concept. Do not pick after-save unless other actions are involved.
Tip 2: Emails, tasks, related records, Chatter, or approvals mean after-save. Any action that requires the record ID or touches other records requires an After-Save (Actions and Related Records) Flow.
Tip 3: Time-dependent actions become Scheduled Paths. If the question mentions sending a reminder X days before or after a date, the correct Flow answer is a Record-Triggered Flow with a Scheduled Path. Do not choose a Schedule-Triggered Flow unless the scenario describes a batch process that runs for all records at a set time regardless of a record change.
Tip 4: Know what the Migrate to Flow tool can and cannot do. It supports Workflow Rules with field updates, email alerts, tasks, outbound messages, and time-dependent actions, and it supports many Process Builder processes. Processes with Apex actions or unusual configurations may need manual rebuilding. If a question says the tool failed or is unavailable for a process, the answer involves manually building the Flow.
Tip 5: Deactivate, don't delete, after migration. Questions about the migration procedure expect you to test in a sandbox, activate the Flow, and then deactivate the legacy automation. Deleting first or running both indefinitely are wrong answers.
Tip 6: Consolidate when possible. If a question describes several Workflow Rules on the same object and asks for the best practice, favor the answer that consolidates them into a single Record-Triggered Flow using Decision elements, or that uses Trigger Order to control sequencing.
Tip 7: Recognize execution-order traps. If a scenario describes unexpected behavior where a Flow runs twice or a field value is overwritten, the likely cause is a legacy Workflow Rule or Process still active on the same object, causing recursion. The fix is to complete the migration and deactivate the legacy automation.
Tip 8: Entry criteria replicate Process Builder's "edited to meet criteria" option. If a question asks how to ensure the Flow only fires when a record changes to meet criteria rather than on every edit, the answer is the "Only when a record is updated to meet the condition requirements" setting in the trigger configuration.
Tip 9: Eliminate answers that suggest building new Workflow Rules or Processes. Since these tools are retired for new automation, any answer that proposes creating a new Workflow Rule or Process Builder is incorrect. The exam is testing whether you know Flow is the only supported path forward.
Tip 10: Watch for keywords. "Efficient" or "performance" usually points to before-save Flows. "Related records" or "child records" points to after-save. "Days after" or "reminder" points to Scheduled Paths. "Apex" points to invocable actions and manual rebuild. "Order" points to Trigger Order or consolidation.
Summary
Migrating from Workflow Rules and Process Builder to Flow is both a practical necessity and a well-represented exam topic. Master the Migrate to Flow tool, understand the distinction between before-save and after-save Record-Triggered Flows, know how Scheduled Paths replace time-dependent actions, and internalize the best practices of consolidation, sandbox testing, and prompt deactivation of legacy automation. With these fundamentals, you will be well prepared to handle any migration scenario the Advanced Administrator exam presents.
Test mode:
Admin II - Migrating Workflow Rules and Process Builder to Flow Example Questions
Test your knowledge of Migrating Workflow Rules and Process Builder to Flow
Question 1
Northern Trail Outfitters' administrator ran the Migrate to Flow tool on a Case workflow rule that sends an email alert and updates Priority. During sandbox testing, the administrator activates the new record-triggered flow. Now a single case save produces two identical customer emails. The debug log shows the Priority update coming from two separate automations in the same transaction. What explains this behavior?
Question 2
Cloud Kicks is retiring a legacy workflow rule. When an Opportunity's Stage changes to Closed Won, the rule sets a custom Close Status picklist on that same Opportunity. Nothing else happens. The administrator is rebuilding the logic and wants the replacement to run as efficiently as possible and use the fewest resources. Which automation should the administrator build?
Question 3
When the Migrate to Flow tool converts a workflow rule or process, what is the activation state of the generated flow and of the original automation once the conversion completes?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Migrating Workflow Rules and Process Builder to Flow questions
30 questions (total)
Other Process Automation concepts
Approval Processes: Steps, Approvers and ActionsAutolaunched Flows and SubflowsBefore-Save Versus After-Save Record-Triggered FlowsBulkification and Governor Limits in FlowsChoosing the Right Declarative Automation ToolDebugging Flows and Flow Error EmailsEmail Alerts and Outbound MessagesEntry Conditions and Run-When-Updated CriteriaFault Paths and Error Handling in FlowsFlow Trigger Explorer and Trigger OrderFormula Fields and Validation Rules in Automation DesignGet Records, Loops, Collections and Decisions in FlowMulti-Step and Parallel ApprovalsOrder of ExecutionPlatform Event-Triggered FlowsScheduled Paths and Schedule-Triggered FlowsScreen FlowsTroubleshooting Approval Processes and Record LockingTroubleshooting Automation with Debug Logs