You cannot create new workflow rules through the standard Setup UI as of Winter '23. The instructions below cover the realistic activities for any modern Salesforce team: auditing existing workflow rules, editing them carefully, and migrating them to Flow. If you must add net-new automation, build it in Flow from the start.
- Audit the existing workflow rules
Setup > Workflow Rules shows every active and inactive rule across the org. Export the list with a metadata retrieve (Workflow.workflowRules member) to a spreadsheet for analysis. Note which objects have the most rules, which rules have time-dependent actions, and which fire field updates that re-evaluate workflow.
- Edit an existing workflow rule
Setup > Workflow Rules > select the rule > Edit. You can adjust criteria, add actions, or modify the evaluation timing. Be careful with criteria changes on rules that fire field updates because changing the trigger condition can leave records in unexpected states.
- Plan the migration to Flow
Inventory the rules by object. Group related rules that fire on the same object and bundle them into one record-triggered flow per object. Note any time-dependent actions because Flow Scheduled Paths configure them differently and need explicit testing.
- Use the Migrate to Flow tool for simple cases
Setup > Migrate to Flow runs the Salesforce-provided converter on selected workflow rules. It handles single-rule conversions cleanly but struggles with cross-object updates and time-dependent actions. Treat the output as a starting point, not a finished migration.
- Rebuild complex rules manually in Flow
For rules the converter cannot handle, build the equivalent record-triggered flow by hand. Use Decision elements to branch the logic, Assignment elements to set field values, and Scheduled Paths to replicate time-dependent actions. Test thoroughly against sandbox data before deploying.
- Deactivate the migrated workflow rule
Once the Flow version is verified, deactivate the workflow rule rather than deleting it. Salesforce keeps the rule available for re-activation if the migration introduces a regression, and audit history retains visibility into the prior automation.
- Document the migration in a runbook
Record which workflow rules were migrated, when, and to which Flow. Include rollback steps. Future engineers will thank you when a regression appears six months later and they need to understand why a rule was changed.
The Salesforce object the workflow rule applies to. Cannot be changed after the rule is created.
When the rule fires: on create only, on create or edit, or on create and edits that match the criteria.
The filter that defines which records qualify. Supports field comparisons, AND/OR logic, and formula evaluation.
- You cannot create new workflow rules through the standard Setup UI as of Winter '23. The New button is gone, and net-new automation must be built in Flow.
- Workflow field updates with "Re-evaluate Workflow Rules" enabled can chain rules across the same record save, producing recursive behavior that is hard to debug. Trace the chain before enabling.
- Time-dependent actions sit in a queue until the schedule fires. Changing the rule criteria after queueing can leave actions in the queue that no longer match the current rule definition.
- The save order matters. Workflow runs after Apex Before triggers but before Apex After triggers. Field updates from workflow may not fire Apex After trigger logic the developer expects without "Re-evaluate" enabled.
- Migrate to Flow tool handles single-rule conversions but fails on cross-object updates and complex time-dependent logic. Treat its output as a starting point, never a finished migration.