Workflow Field Update
A Workflow Field Update is a type of workflow action in Salesforce that automatically changes the value of a field when its parent workflow rule fires.
Definition
A Workflow Field Update is a type of workflow action in Salesforce that automatically changes the value of a field when its parent workflow rule fires. It can set a value on the same record that triggered the rule, or, in limited master-detail cases, on a related parent record. Admins reached for it to stamp dates, flip statuses, set checkboxes, and recalculate values without writing code.
Field updates are a legacy feature. Salesforce stopped letting orgs create new workflow rules in Winter '23 and ended support for Workflow Rules and Process Builder on December 31, 2025. Existing rules still run, but the modern replacement is a record update inside a record-triggered Flow.
How field updates worked, and where Flow takes over
What a field update actually did
A field update was one of several action types you could attach to a workflow rule, alongside email alerts, tasks, and outbound messages. When the rule's criteria evaluated to true, the field update ran and wrote a new value into a target field. The value could be a specific literal you typed, a blank value that cleared the field, or the result of a formula. Picklist fields added two extra choices: set the value to the option directly above or directly below the current selection in the picklist's defined order, which was handy for simple stage progression. The most common use was small and practical. Teams stamped a "Date Closed" when a Status changed, checked an "Escalated" box, or copied a value from one field into another. Because the action sat inside the platform's save process, it ran server-side every time the rule fired, with no Apex involved. That low barrier is why field updates became the single most-used workflow action across most orgs, and why so many of them now need migrating.
Where it ran in the order of execution
Field updates fire late in the save. Salesforce runs before triggers, then system and custom validation rules, then after triggers, then assignment and auto-response rules, and only then workflow rules and their field updates. So a field update never blocks a save, and it cannot stop a record from being committed the way a validation rule can. There is one behavior that trips people up. When a field update changes a value, the record is updated again, and that re-save fires before and after update triggers one more time, but only once more. Standard validation still runs on that second pass, yet your custom validation rules do not run again. Apex written for a single update can therefore execute twice for one user action. Plenty of hard-to-trace bugs came from a trigger that assumed it ran exactly once, then quietly ran a second time because a workflow field update touched the same record.
Cross-object updates and their tight limits
A field update usually changed the record that fired the rule. In specific cases it could reach across to a related record, but only over particular master-detail paths, never a lookup. A custom object could update a field on its master object. Among standard objects the supported hops were narrow: a Case Comment could update its Case, an Opportunity Product could update its Opportunity, and an Opportunity could update its Account. This is far more restrictive than what people expect from automation today. You could not freely update any related record, and you could not chain updates across several objects in one action. The narrowness of cross-object field updates is one of the clearest reasons Salesforce pushed everyone toward Flow. A record-triggered Flow can query and update almost any related records with Get and Update elements, with no master-detail requirement and no fixed list of allowed object pairs.
Re-evaluating rules and the loop guard
Field updates included an option labeled "Re-evaluate Workflow Rules after Field Change." When checked, changing the field would make Salesforce re-run the object's workflow rules, so a rule that depended on a value set by another rule could still fire. Without it, that downstream rule might be skipped because it was evaluated before the value changed. To stop this from spiralling, the platform capped re-evaluation. Workflow rules could be re-evaluated only one additional time based on the original event, which protected against endless loops between rules that kept triggering each other. The option also carried a restriction: you could not turn on "Re-evaluate Workflow Rules after Field Change" for a cross-object (parent) field update. Reasoning through which rule sets your value, in what order, and whether re-evaluation is needed was one of the more confusing parts of workflow design. Flow replaces that guesswork with an explicit, visible sequence of elements you control directly.
Fields you could not touch
Not every field was a valid target. You could not update a formula field, because its value is derived rather than stored. You could not write into most standard read-only or system audit fields either. Roll-up summary fields were off limits for the same reason as formulas, since the platform calculates them. One quirk worked in the admin's favor. A workflow field update ran with the system's authority and ignored field-level security and page-layout settings. That meant a field update could set a value the running user was not even allowed to see or edit through the UI. It was useful for back-office stamping, but it also meant a value could change in a way no user could account for by looking at their own access. When you migrate to Flow, a record-triggered Flow runs in system context by default too, so this convenient behavior carries over without special configuration.
Migrating to Flow with the Migrate to Flow tool
Salesforce ships a Migrate to Flow tool to convert legacy automation. From Setup, enter "Migrate to Flow" in Quick Find and open it, or click the migrate link on the Workflow Rules page. You select a workflow rule, run the conversion, and Salesforce builds a record-triggered Flow that reproduces its actions, including same-record field updates and email alerts. You then test the new Flow in Flow Builder, deactivate the original workflow rule, and activate the Flow. A clean target is one Flow per object that runs on create or update. Inside it, a field update becomes an Assignment that sets the value followed by an Update Records element, or in many cases an Update element acting on the triggering record directly. The result is usually as fast as the old field update, and often faster, while giving you branching, related-record access, and a single place to read all of an object's automation rather than scattered rules.
Replace a workflow field update with a Flow
Field updates are legacy, so the right move is to recreate the behavior in a record-triggered Flow rather than build a new workflow rule. Here is the practical path for a same-record field update, the most common case.
- Open the existing rule
From Setup, find Workflow Rules and open the rule whose field update you want to replace. Note its evaluation criteria, the field it sets, and the value it writes.
- Run the Migrate to Flow tool
From Setup, enter Migrate to Flow in Quick Find, open it, select the workflow rule, and run the conversion. Salesforce generates a record-triggered Flow that mirrors the rule's field updates and email alerts.
- Review the generated Flow
Open the new Flow in Flow Builder. Confirm the entry conditions match the old criteria and that the Update element writes the correct field and value on the triggering record.
- Test before cutover
Save and debug the Flow, or test in a sandbox, to confirm it sets the field exactly as the workflow rule did across create and update scenarios.
- Deactivate the rule, activate the Flow
Once the Flow behaves correctly, deactivate the original workflow rule and activate the Flow so the same record is never updated by both.
Run the Flow on create, on update, or on both, matching when the old rule evaluated. Fast field changes belong in a before-save Flow.
For same-record field changes, a before-save record-triggered Flow sets the value without a second DML, the fastest equivalent of a field update.
Recreate the workflow rule criteria as the Flow's entry conditions so the value is only set when it should be.
- You cannot create new workflow rules since Winter '23, so do not try to rebuild a field update as a workflow action. Build it in Flow.
- A before-save Flow that sets a same-record field is much faster than the old after-save field update and avoids a second round of triggers.
- The Migrate to Flow tool handles same-record field updates and email alerts well, but review cross-object field updates by hand because their object support was always narrow.
- If multiple legacy rules touched one object, consolidate them into one record-triggered Flow so the order of field changes stays predictable.
Trust & references
Cross-checked against the following references.
- Field Update ActionsSalesforce
- Salesforce Workflow Rules and Process Builder End of SupportSalesforce
Straight from the source - Salesforce's reference material on Workflow Field Update.
- Field Update ActionsSalesforce
- Triggers and Order of Execution (Apex Developer Guide)Salesforce
Hands-on resources to go deeper on Workflow Field Update.
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 a Workflow Field Update?
Q2. What replaces them?
Q3. Can they update related records?
Discussion
Loading discussion…