A workflow field update in Salesforce is an automated action that changes the value of a field on a record when a Workflow Rule (or an approval or entitlement process) fires — for example, ticking a checkbox, stamping a date, or recalculating a status without anyone editing the record by hand.
The important 2026 reality: Salesforce no longer lets you create new Workflow Rules or Process Builder processes in most orgs, and it now steers all record automation to Salesforce Flow. If you still have workflow field updates running, they keep working for now — but the modern, supported way to do the same job is a record-triggered Flow with an Update Records element.
Key takeaways
- A workflow field update automatically writes a value to a field when a rule's criteria are met.
- It can update the triggering record, or — in master-detail relationships — the related master record.
- Workflow Rules and Process Builder are on Salesforce's retirement path; new ones generally can't be created, and migration to Flow is the recommended direction.
- The direct replacement is a before-save record-triggered Flow (fastest, for same-record updates) or an after-save Flow (for related records and other actions).
- Use the built-in Migrate to Flow tool to convert existing Workflow Rules — and their field updates — into flows.
What does a workflow field update do?
A workflow field update belongs to the older Workflow Rules automation engine. A Workflow Rule watches a record for a trigger, checks its criteria, and — when the criteria are true — runs one or more actions. A field update is one of those actions, alongside email alerts, tasks, and outbound messages.
Typical things teams automated with a field update:
- Stamp an "Approved on" date when an approval completes.
- Flip a checkbox (for example
High_Priority__c) when an amount crosses a threshold. - Recalculate a Status or Stage based on other field values.
- Reassign a record's owner as a step inside an approval process.
Field updates were never limited to Workflow Rules. The same action could also be attached to approval processes and entitlement processes, which is why you may still see field updates referenced in several places across an older org.
How was a classic workflow field update set up?
In orgs that still have Workflow Rules, the path is Setup → Process Automation → Workflow Rules (older menus showed Create → Workflow & Approvals → Field Updates). The configuration has a few moving parts worth understanding before you migrate them.
Evaluation criteria — when the rule runs
Each Workflow Rule chooses when to evaluate the record:
- Created — only when a record is first created.
- Created, and every time it's edited — on create and on every subsequent save.
- Created, and any time it's edited to subsequently meet criteria — fires again only when a record newly transitions into meeting the criteria.
Rule criteria — the condition
The condition is defined either as filter logic (field / operator / value rows) or as a formula that must evaluate to true.
The field update action
You then define the field update itself: pick the object, pick the field to change, and choose the new value:
- A specific value you type in.
- A blank (null) value to clear the field.
- A formula that computes the value from other fields.
For record owners you pick a user or queue; for checkboxes, True or False; for picklists, a specific entry. The unique name (API name) may contain only letters, numbers, and single underscores, and can't start or end with an underscore.
Re-evaluate Workflow Rules after field change
The "Re-evaluate Workflow Rules after field change" option tells Salesforce to run all Workflow Rules on the object again if the field update actually changed the value. It is powerful, but it is also a classic source of recursion and hard-to-trace loops — one of the reasons Flow's more predictable execution model is preferred today.
A few long-standing behaviours to remember: field updates run before email alerts, tasks, and outbound messages, but after assignment and auto-response rules; they ignore field-level security; and read-only fields such as formula and auto-number fields can't be targeted.
Why should you move field updates to Flow?
Salesforce has publicly placed Workflow Rules and Process Builder on the end-of-life path. In practice today:
- You generally cannot create new Workflow Rules or Process Builder processes in orgs created after the cutover — the buttons are gone or redirect you to Flow.
- Existing automations still run for now, but Salesforce has announced they will eventually be retired. (Salesforce has shifted the exact end date more than once, so treat any specific date as provisional and confirm it in current Salesforce release notes rather than relying on a number you read in a blog.)
- All new investment — performance, features, and debugging tools — is going into Salesforce Flow.
For a field update specifically, the modern equivalent is a record-triggered Flow that uses an Update Records element. If you are consolidating older automation, see our walkthrough of Process Builder in Salesforce, which sits on the same retirement path and should also be migrated to Flow.
The modern replacement: a record-triggered Flow
A record-triggered Flow runs automatically when a record is created, updated, created-or-updated, or deleted — the same idea as a Workflow Rule's evaluation criteria, but far more capable. When you replace a field update, the key choice is when the flow runs.
Before-save (fast field updates)
A before-save record-triggered flow runs during the same database transaction, before the record is committed. To update fields on the record that triggered the flow, you set values directly on the $Record variable — no separate Update Records query is needed. This is the closest, fastest analog to a classic workflow field update, because it avoids a second save entirely.
Use before-save when you only need to update fields on the triggering record. A before-save Flow formula that mirrors an old field-update formula looks like this:
/* Flow formula resource: Is_High_Priority (Checkbox)
Equivalent to an old workflow field-update formula.
Used in a before-save record-triggered Flow on Opportunity. */
AND(
{!$Record.Amount} >= 50000,
ISPICKVAL({!$Record.StageName}, "Proposal/Price Quote")
)After-save
An after-save flow runs after the record is committed. You need after-save when you must:
- Update related records (for example, the parent account).
- Send emails, create records, call subflows, or invoke actions.
- Reference values that only exist after the save, such as the new record Id on create.
A rough rule of thumb: same-record field changes → before-save; everything else → after-save.
Workflow field update vs Process Builder vs Flow
| Aspect | Workflow Rule field update | Process Builder | Flow (before-save update) |
|---|---|---|---|
| Status in 2026 | Retirement path | Retirement path | Actively developed; recommended |
| Can you create new ones? | No (most orgs) | No (most orgs) | Yes |
| Same-record update speed | Extra save (slower) | Extra save (slowest) | No extra save (fastest) |
| Update related records | Master only (master-detail) | Yes | Yes (after-save) |
| Complex logic / branching | Limited | Moderate | Full (loops, decisions, subflows) |
| Debugging | Debug logs only | Limited | Flow debugger + error handling |
| When to use today | Maintain existing only | Maintain existing only | All new automation |
The takeaway: for any new same-record field update, build a before-save record-triggered Flow. Keep existing Workflow Rules running only until you can migrate them.
Using the "Migrate to Flow" tool
Salesforce ships a built-in Migrate to Flow tool (Setup → Process Automation → Migrate to Flow) that converts existing Workflow Rules — including their field updates — into record-triggered flows automatically. A practical approach:
- Inventory your active Workflow Rules and the field updates each one runs.
- Run Migrate to Flow on one rule at a time and review the generated flow.
- Test in a sandbox, then activate the new flow and deactivate the old Workflow Rule.
- Consolidate — aim for a small number of well-ordered record-triggered flows per object rather than many overlapping rules.
Things to watch when migrating
- Order of execution — a before-save flow runs before old Workflow Rules, so running both during a partial migration can change outcomes. Migrate a given object fully where you can.
- Recursion — replace "re-evaluate Workflow Rules after field change" behaviour with deliberate entry conditions and the "only when a record is updated to meet the condition" option in Flow.
- Read-only fields — formula and auto-number fields still can't be written by either tool.
- Governor limits — heavy related-record updates count against limits, so batch logic where you can.
If your team needs hands-on help untangling legacy Workflow Rules, approval automations, and field updates, MicroPyramid's Salesforce consulting and managed services team has migrated automation for organizations since 2014 across 50+ delivered projects. We also build time-based nudges with Flow — see how to create automatic reminders in Salesforce.
Frequently Asked Questions
What is a field update in a Salesforce workflow?
A field update is a Workflow Rule action that automatically changes the value of a field on a record when the rule's criteria are met — for example, setting a checkbox, clearing a value, or writing a formula result. It runs without anyone manually editing the record.
Can I still create new workflow field updates in 2026?
In most orgs, no. Salesforce has stopped allowing the creation of new Workflow Rules (and Process Builder processes) and now directs all record automation to Flow. Existing workflow field updates generally still run, but you should plan to migrate them to a record-triggered Flow.
What is the modern replacement for a workflow field update?
A record-triggered Flow. To update fields on the same record that triggered it, use a before-save flow and set values on the $Record variable — this is the fastest, most direct equivalent. Use an after-save flow when you need to update related records or perform other actions.
What is the difference between a before-save and after-save Flow update?
A before-save flow runs during the same transaction and updates the triggering record with no extra save, which makes it ideal for same-record field changes. An after-save flow runs after the record is committed and is required for updating related records, sending emails, or creating other records.
Will my existing Workflow Rules stop working?
Not immediately. They keep running for now, but Salesforce has placed Workflow Rules and Process Builder on the retirement path. Salesforce has revised the exact end date more than once, so confirm the current timeline in the latest release notes and migrate proactively rather than waiting for a hard cutoff.
How do I migrate workflow field updates to Flow?
Use the built-in Migrate to Flow tool under Setup → Process Automation. Convert one Workflow Rule at a time, review and test the generated flow in a sandbox, then activate it and deactivate the old rule. For complex or interdependent automation, a guided migration helps you avoid order-of-execution surprises.