In 2026, the operational task around Workflow Tasks is migration, not creation. New automation should use Flow from the start; existing Workflow Tasks should be migrated to Flow on a schedule. The Migrate to Flow tool in Setup automates most of the work, but the converted Flows still need review, testing, and activation before the original Workflow Rule can be deactivated. This guide covers the migration routine end to end, since that is what every Salesforce admin running an established org needs to know.
- Inventory existing Workflow Tasks
From Setup, open Workflow Rules and list every active rule. For each rule, note the object, the trigger criteria, the actions (including any Workflow Tasks), and the assignee, subject, and due-date logic on each Task. Export the inventory to a spreadsheet for the migration tracker. Group rules by object and by complexity; simple single-task rules can be migrated in bulk, while multi-action rules with field updates and tasks need individual review. The inventory is the source of truth for the migration scope; do not start until it is complete.
- Run the Migrate to Flow tool for each rule
From Setup, search Migrate to Flow. Select a Workflow Rule from the list and click Migrate. The tool generates an equivalent record-triggered Flow with one Decision element per rule criterion and one Create Records (or other action) element per Workflow action. Review the generated Flow carefully. The tool is conservative and may not pick the optimal Flow design; rename elements for clarity, consolidate redundant Decision branches, and confirm the Task template fields map to the right Flow variables. Save the Flow as a draft until testing is complete.
- Test the converted Flow in a sandbox
Refresh a sandbox with the production configuration, deploy the draft Flow, and trigger it manually with representative source records. Confirm Tasks are created with the right assignee, subject, status, priority, and due date. Compare the output to what the original Workflow Rule produces in the same scenario; the two should be functionally identical. Add unit tests if the Flow has Apex action calls. Capture any divergence in a defect tracker and fix the Flow before activating in production. Skipping this step is the most common cause of post-migration support tickets.
- Activate the Flow, deactivate the Workflow Rule, and monitor
In production, activate the new Flow. Watch for the first few Tasks it creates and confirm they look right. Once you are confident (typically after a few days of clean operation), deactivate the original Workflow Rule. Do not delete the Workflow Rule immediately; keep it inactive for 30 days as a rollback option. After 30 days of clean Flow operation, delete the Workflow Rule and remove it from your migration tracker. Document the migration in the org automation registry so future admins know which Flow replaced which legacy rule.
- Workflow Tasks fire even when the original assignee is inactive. The Task creation may fall back to a default user or fail silently. Audit your active assignees on Workflow Tasks before migration.
- The Migrate to Flow tool is conservative. It generates a functionally correct Flow but not always an optimal one. Review the generated Flow and refactor for clarity before promoting to production.
- Workflow Rules will be retired. Salesforce has not given a hard date, but new investment is on Flow only. Treat any new automation requirement as Flow work; do not add new Workflow Tasks.
- Activating the Flow without deactivating the Workflow Rule creates duplicate Tasks. The conversion period needs careful sequencing: activate Flow, validate, then deactivate the Workflow Rule, never both active at once.
- Workflow Task templates do not version. Editing the template in production changes behavior for every rule that uses it. Migrate to Flow per rule, not per template, to maintain isolation.