Workflow Rule
A workflow rule is a Salesforce automation tool that fires one or more actions (field update, email alert, task creation, or outbound message) when a record meets defined criteria on create or edit.
Definition
A workflow rule is a Salesforce automation tool that fires one or more actions (field update, email alert, task creation, or outbound message) when a record meets defined criteria on create or edit. It was the platform's first declarative automation framework and ran most no-code business logic from 2007 until Process Builder and Flow took over in the late 2010s. Workflow rules still exist in most established orgs, but Salesforce stopped allowing new ones in late 2022 and is steering all customers toward Flow.
A workflow rule has three pieces: an evaluation criterion (when to consider the rule), a rule criterion (which records qualify), and a list of actions to fire. The actions can run immediately when the rule fires, or be time-dependent and queued for the future. Workflow rules are still active and supported on records, but as of Winter '23 you can no longer create new ones in Setup; you can only edit existing rules. Most modernization projects either leave the rules in place or migrate them to Flow as part of broader automation consolidation work.
How workflow rules still shape automation in legacy Salesforce orgs
The deprecation timeline and what it means today
Salesforce announced the workflow rule sunset alongside Process Builder in the late 2010s, and the Setup UI removed the New button for workflow rules starting Winter '23. Existing rules continue to execute and remain editable, but no new rules can be created through the standard UI. Customers can still migrate or recreate the underlying logic in Flow, which is the platform's go-forward automation framework. Workflow rules are not scheduled for removal yet, but every roadmap conversation includes a future end-of-life date that has not been set publicly.
The four action types and their behavior
A workflow rule can fire four kinds of actions. Field Update writes a value to a field on the same record or its parent. Email Alert sends a templated email to recipients defined in the alert configuration. Task creates a new Task record assigned to a user or queue. Outbound Message posts an XML payload to an external endpoint, a feature mostly replaced by Platform Events and named credentials. Each action is reusable: one Field Update can be referenced by multiple workflow rules across the same object.
Evaluation criteria and the recursion problem
Workflow rules evaluate at one of three times: when a record is created, when a record is created or every time it is edited, or when a record is created and any time it is edited to meet the criteria. The third option avoids re-firing on edits that did not change the matching condition. Re-evaluating workflow on field updates can create a chain that fires unintended rules elsewhere; the "Re-evaluate Workflow Rules after Field Change" checkbox on the Field Update action triggers this cascade. Most legacy orgs have at least one recursive workflow surprise in their history.
Time-dependent actions and the queue
Workflow rules support time-dependent actions that fire on a relative schedule, like "30 days after Close Date" or "1 hour before Renewal Date". The queued actions sit in a time-based queue visible at Setup > Time-Based Workflow. If the rule criteria stops being met before the scheduled time, the action is removed from the queue. This is a powerful pattern that Flow replicates with Scheduled Paths but configures very differently, which is one reason migrations are not straightforward find-and-replace.
Workflow versus Process Builder versus Flow
Salesforce introduced Process Builder in 2015 as the workflow rule successor, then announced in 2021 that Process Builder itself would also be deprecated in favor of Flow. The result is three generations of declarative automation alive in production orgs: workflow rules from 2007, processes from 2015, and flows from the late 2010s onward. Each does similar things with different UX. The migration recommendation today is to move everything to Flow over time, but the work is rarely urgent enough to prioritize.
Order of execution and where workflow fits
Workflow rules execute as a specific step in the Salesforce save order, after Apex Before triggers, validation rules, and Apex DML, and before Apex After triggers, escalation rules, and assignment rules. The Order of Execution document is one of the most important debugging references in any Salesforce engineering team's bookmark list. Knowing where workflow falls in the save order explains why field updates from workflow rules sometimes do not visibly fire trigger logic the developer expects.
Migration strategies to Flow
Three approaches dominate workflow-to-Flow migrations. Rebuild manually, which is precise but slow. Use the Salesforce-provided Migrate to Flow tool, which converts simple workflow rules but struggles with cross-object updates and time-dependent actions. Or rebuild as a single record-triggered flow per object, consolidating multiple workflow rules into one entry point with branching logic. The last approach is the cleanest but requires the most up-front design work and the most thorough testing.
How to maintain (and migrate) Workflow Rules
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.
Trust & references
Cross-checked against the following references.
- Workflow Rules OverviewSalesforce Help
- Manage Workflow RulesSalesforce Help
- Workflow Rule and Process Builder RetirementSalesforce Help
Straight from the source - Salesforce's reference material on Workflow Rule.
- Manage Workflow RulesSalesforce Help
- Migrate to Flow ToolSalesforce Help
- Order of ExecutionSalesforce Developer
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the main advantage of using Workflow Rule over writing Apex code?
Q2. When should you consider using Workflow Rule in your Salesforce org?
Q3. What type of Salesforce feature is Workflow Rule?
Discussion
Loading discussion…