Field Update
A Field Update is a Workflow action that automatically sets a specific field on a record to a defined value when the workflow rule fires.
Definition
A Field Update is a Workflow action that automatically sets a specific field on a record to a defined value when the workflow rule fires. The action is one of four classic Workflow action types (Field Update, Email Alert, Task, Outbound Message), and historically was the foundation for declarative data automation in Salesforce. Field Updates can set the field to a literal value, a formula result, or clear it entirely. They run before or after the record save depending on configuration, with implications for downstream automation.
The action is functionally available in modern Salesforce but mostly retired in favor of Flow. Workflow Rules and their Field Update actions were officially deprecated in 2022, with Salesforce announcing the path forward as Flow Builder. Existing Workflow Rules continue to run, but new automation should be built in Flow. Understanding Field Update still matters because thousands of legacy orgs run on Workflow, and migration to Flow requires reproducing Field Update behavior in Flow Update Records elements.
How Field Update works in Workflow
The four Workflow action types
Workflow Rules support four action types. Field Update changes a field value. Email Alert sends an email. Task creates a Task record. Outbound Message sends data to an external endpoint. Of the four, Field Update is the most commonly used and the one that survives most cleanly in the migration to Flow. The other three have direct Flow analogs but with different mechanics.
Setting a literal value or a formula
A Field Update can set the field to a constant, evaluate a formula at runtime, or set the field to blank. Formula updates are the most powerful: you can reference any field on the record, related records (through dot notation), and standard formula functions. The formula evaluates at runtime against the saved record values, which means subsequent updates within the same transaction can override the result if rule order is not handled carefully.
The recursive trigger problem
Field Updates that trigger Apex triggers, Process Builder processes, or other Workflow Rules can create recursive evaluation loops. Salesforce includes guardrails (a recursive depth limit), but the symptom in production is usually a record save that takes seconds instead of milliseconds, or worse, an "Apex CPU limit exceeded" error during bulk operations. Identifying recursive Field Update chains is one of the harder org-cleanup tasks; trace every Workflow that updates a field that another rule reads.
Re-evaluation after Field Updates
The Re-evaluate Workflow Rules After Field Change checkbox on the Workflow Rule controls whether other rules re-fire after this rule updates a field. Off: the field changes silently and downstream rules do not see it. On: other rules evaluate again with the new value, which can cascade. The default is on, which is the source of much surprise behavior. Audit this setting before assuming a Field Update will run cleanly.
Migrating to Flow
Workflow is deprecated; new automation belongs in Flow. The Migrate to Flow tool in Setup converts a Workflow Rule into a Flow, including Field Update actions translated as Update Records elements. The conversion is mostly mechanical but produces verbose Flows. Most teams write the Flow from scratch using the Workflow as a reference, because the Flow ends up cleaner and easier to maintain.
Permission considerations
Field Updates run in system context, bypassing the user's field-level security on the updated field. This is the source of "I cannot edit this field but it keeps changing" complaints: a Workflow Rule is updating a field the user does not even see. Audit Field Updates affecting FLS-restricted fields and document the system behavior, otherwise users will keep filing tickets about a value they cannot read but are being told changed.
Limits and licensing
Each Workflow Rule can have up to 10 Field Updates. The total Workflow Rule count per object is 50, and the total active rules across the org is 500. These limits apply only to legacy Workflow; Flow has different limits and is the strategic platform. Hitting Workflow limits is increasingly a sign that migration to Flow is overdue rather than a reason to optimize Workflow further.
Maintain and migrate Field Updates
Maintaining legacy Field Updates is the realistic task today, since new automation should go in Flow. The steps below cover both updating an existing Field Update and the recommended migration path.
- Locate the Field Update
Setup > Workflow Actions > Field Updates. The list shows every Field Update in the org with its name, target object, and target field.
- Audit the calling Workflow Rule
From the Field Update detail page, see which Workflow Rules reference it. Confirm the rule conditions and the rule's evaluation criteria before editing the update.
- Edit the value or formula
Click Edit on the Field Update. Update the literal value, formula, or blank option. Save.
- Re-evaluate the impact
Test in a sandbox: update a record matching the rule and confirm the field updates as expected. Check for cascading rule evaluations.
- Document in change log
Record the change in the team's change log or release notes. Workflow Field Updates are easy to lose track of; documentation is the primary defense against orphan automation.
- Plan migration to Flow
Add the Workflow Rule and its Field Updates to your Flow migration backlog. The Migrate to Flow tool gives a starting point; refactor in Flow Builder for maintainability.
- Deprecate the Workflow
After the Flow is deployed and tested, deactivate the Workflow Rule rather than deleting. Deactivation preserves history; deletion removes the audit trail.
Set the field to a constant value (Status = Closed). The simplest update type.
Evaluate a formula at runtime. Can reference fields on the record and related records through dot notation.
Clear the field. Useful for resetting state fields when conditions change.
Causes other rules to re-evaluate after the update. Default on; source of cascading behavior.
Field Update can fire immediately on save or as part of a time-dependent action scheduled minutes/hours later.
- Workflow is deprecated. Adding new Field Updates rather than migrating to Flow accumulates technical debt that gets harder to migrate over time.
- Field Updates bypass field-level security. Users without FLS see the field change without being able to read or write it; explain this clearly to support teams.
- Cascading rule re-evaluation can create infinite loops. Salesforce caps recursive depth but the symptom is mysterious save slowness or CPU-limit errors.
- Migrate to Flow tool produces verbose output that is often less maintainable than a hand-built Flow. Use it as a starting point, not a final artifact.
- Deactivating a Workflow Rule preserves history; deleting removes the audit trail. Default to deactivation when migrating to Flow.
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 does a Field Update do?
Q2. Where should new field update automation be built?
Q3. What's a risk with Field Updates that trigger re-evaluation?
Discussion
Loading discussion…