Home / admin / workflow-field-update-patterns

workflow-field-update-patterns

Cross-tool decision matrix for field-update automation in Salesforce — Before-Save Flow vs After-Save Flow vs Apex Trigger vs the deprecated Workflow Rule + Field Update.

• v1.1.0
• Salesforce Spring '25+
• Updated 2026-09-04
• Reliability
• Operational Excellence

• field-update
• automation-selection
• before-save-flow
• after-save-flow
• apex-trigger
• workflow-rule-migration

Open the skill folder on GitHub

Workflow Field Update Patterns

The most common automation question in Salesforce admin work: "I need to set field X to Y when condition Z." The answer depends on whether X is on the same record being saved (cheap, before-save flow), the parent (cross-object after-save), or a child (multi-record DML), plus volume, recursion risk, and whether the value can be derived as a formula instead of stamped.

This skill is the decision layer. It does NOT teach you to build the chosen tool — flow/flow-best-practices, apex/trigger-framework, and so on cover that. It also doesn't redefine the Salesforce order-of-execution sequence — see admin/order-of-execution.

What this skill IS: a decision matrix between the four field-update tools (formula, before-save flow, after-save flow, Apex trigger), plus the migration playbook for replacing legacy Workflow Rule field-update actions (deprecated as of late-2022).

Before Starting

• Confirm the field-update need. If the value is purely a

  derivation of other fields on the same record, a formula field is the right answer — no automation needed at all. Don't reach for flow / trigger if formula fits.

• Identify the target record. Same record being saved, parent,

  child, unrelated. Different targets need different tools.

• Identify the volume. < 200 records per save event = standard

  paths. Bulk loads of 1M records hit Apex governor budgets that Flow can't always handle.

• Inventory existing automation on the target object. Adding a

  new before-save flow to an object that already has 3 triggers and 2 flows is the recursion-risk territory.

Questions to Ask Before Configuring

Ask these before opening Flow Builder. Each one maps to a specific way this goes wrong later; skipping them produces automation that works on the demo record and diverges from the legacy behaviour it replaced.

What a proper configuration adds over just building the Flow: the replacement fires on exactly the saves the old rule fired on, every Apex trigger on the object still runs the number of times its author assumed, and the field-history row after cutover proves which writer produced the value.

Core Concepts

The four field-update tools

The standout: before-save flows updating the same record being saved are governor-free. They don't fire a second DML; they modify the in-flight record before commit. This is the cheapest field-update mechanism on the platform.

Same-record before-save vs same-record after-save

Updating a field on the SAME record being saved:

• Before-save flow / trigger — modify the in-flight record;

  no second DML; no recursion possible (it's the same save event).

• After-save flow / trigger — must issue an Update DML against

  the just-saved record; counts as a second DML; can recurse if the trigger that produced the update fires again on its own update.

The platform charges you (in DML, governor budget, recursion risk) to do the same work after-save that you can do free before-save. Before-save is the right choice unless you specifically need a value that's only computed after the initial save (record Id on insert is the canonical example — but lookup-relationship integrity often makes after-save the wrong shape too).

Recursion: the after-save trap

A record-triggered after-save flow that updates a field on the same record fires again on its own update. Without a guard, infinite loop — Salesforce's recursion-detection cuts it at around 16 levels with an exception. With a guard (a custom static variable, a field-set check, a "do nothing if X is already set" decision branch in the flow), the second invocation no-ops.

The cleanest guards:

• isChanged(Field__c) decision in the flow's entry condition

  — only run if the field-being-updated changed.

• Static Set<Id> recursion sentinel in Apex — track which

  records the trigger has already processed in this transaction.

• Don't write the value if it already matches — decision branch

  before the Update Records element.

Order of execution overlap with other automation

Salesforce's published order-of-execution is a fixed 20-step sequence. The steps this skill touches, using the documented step numbers:

Before-save flows (3) and before-update triggers (4) are separate, ordered steps — the flow always runs first. The same holds for after triggers (8) and after-save flows (14): the trigger always runs first, with steps 9–13 in between. Neither pair is interleaved.

Field updates from flows can fire other before-save flows / triggers. Field updates from after-save automation re-enter the loop — this is the recursion source. Plan for it.

Workflow Rule field-update deprecation

Workflow Rules with Field Update actions stopped being creatable in new orgs and stopped accepting new Field Update actions on existing rules in late 2022. They still RUN in orgs that have them; they're not deleted. The migration target is record-triggered flow — typically before-save for same-record stamps, after-save for cross-object updates. The migration tool surfaces them in Setup; the mapping is straightforward.

Common Patterns

Pattern A — Same-record stamp via before-save flow

When to use. Stamp Account.Last_Reviewed_Date__c to TODAY when Account.Status__c = 'Active'. Same record, derived, no parent / child involvement.

Approach. Record-triggered flow on Account, before-save, entry condition Status__c = 'Active' AND ISCHANGED(Status__c). Single Update Records element setting Last_Reviewed_Date__c = {!$Flow.CurrentDate}. Done.

Why before-save. Free (no DML), no recursion possible.

Pattern B — Same-record stamp where formula would be enough

When to use. Opportunity.Display_Stage__c = "Won (" + TEXT(StageName) + ")" for a custom UI rendering.

Wrong instinct. Build a flow that stamps it on every save.

Right answer. Formula field. Computed at read time, no storage, no automation, no recursion, no stale-value risk.

If the formula approach can express it, that's the right answer. Reach for flow / trigger only when the value can't be expressed as a formula (depends on related-record state that formulas can't traverse, requires history that formulas don't have access to, needs to be settable by other automation downstream).

Pattern C — Cross-object update via after-save flow

When to use. When Case.Status__c = 'Closed', decrement the parent Account.Open_Cases__c by 1.

Approach. Record-triggered flow on Case, after-save (must be after-save — cross-object DML can't happen in before-save). Update Records element on the parent Account, decrementing the field.

Recursion guard. The Account update doesn't fire a Case trigger, so no Case-side recursion. But the Account-side automation may react. Account before-save flow that re-stamps a derived field on Account is fine; Account after-save flow that updates Account's own fields is the standard recursion territory.

Pattern D — Apex trigger when flow can't express the logic

When to use. Field update requires complex logic — a Schema describe call, a callout result, a Type.forName dispatch, a batched DML across multiple objects in one transaction.

Approach. Use templates/apex/TriggerHandler.cls as the base. Recursion guard via static Set<Id>. Bulkify; the trigger fires for batches up to 200 (or 2000 for Platform Event triggers).

The honest cost: Apex requires test coverage, deploy via metadata, admin can't edit it. Use only when flow can't express it.

Pattern E — Migrating Workflow Rule field updates

When to use. Existing org with Workflow Rules that include Field Update actions; modernizing to flow.

Per-rule mapping.

Where each operation lands. WorkflowFieldUpdate.operation has six values and they do not all have a Flow equivalent. The full element-by-element mapping — including entry criteria, trigger type and time triggers — is the table in references/metadata-examples.md.

Migration order. Use Salesforce's Migrate to Flow tool (Setup → Workflow Rules → Migrate to Flow). It produces a draft flow that you review, test, activate, and only THEN deactivate the original Workflow Rule. Don't deactivate first; the gap leaves the field unstamped. Ship the activation and the deactivation as one deploy — references/metadata-examples.md has the cutover manifest and the field-history verification query.

Decision Guidance

Recommended Workflow

1. Inventory before designing. Retrieve Workflow with the wildcard manifest in

   references/metadata-examples.md, then run python3 scripts/check_workflow_field_update_patterns.py --manifest-dir force-app/main/default. The inventory block gives the counts that set the scope: field updates per object, reevaluateOnChange flags, targetObject cross-object updates, time triggers, and rules that already defeated the Migrate to Flow tool.

2. Rule the field out of automation entirely. If the value is a function of same-record

   fields at read time, it is a formula field — references/examples.md Example 4 has the CustomField XML and the one behavioural difference (formulaTreatBlanksAs) to check before deleting the automation it replaces.

3. Answer the seven questions above and route. automation-selection.md Q2 (same record,

   under ~10s) → before-save Flow; Q4/Q5 (crosses objects, linear) → after-save Flow; Q3 (callout retry, savepoints, recursive same-object DML) → Apex on templates/apex/TriggerHandler.cls. flow-pattern-selector.md Q3 confirms before-save vs after-save; Q5 routes a time trigger to a scheduled path.

4. Build from the matching example, not from scratch.

   references/metadata-examples.md Example 2 (before-save Flow), Example 3 (after-save, targetObject case), Example 4 (Apex beforeUpdate excerpt). Map every legacy element through the table there; anything with no row is a design decision to record, not to skip.

5. Fill templates/workflow-field-update-patterns-template.md. Sections 3 and 4 are the

   ones that catch migrations: the element-by-element legacy mapping, and the measured trigger-entry count per save before and after the cutover.

6. Run the checker against the change, not just the org. Re-run

   check_workflow_field_update_patterns.py --manifest-dir <tree> on the branch. Zero ERRORs is the deploy gate; the double-writer WARN firing means the cutover is only half-built.

7. Parity-test, then cut over in one deploy. Run the seven-row table from

   references/metadata-examples.md with the legacy rule live, then with it deactivated — identical results both times. Deploy the Active Flow and <active>false</active> together, then confirm with the field-history query.

Review Checklist

• [ ] Formula field was considered before reaching for flow / trigger.
• [ ] Before-save flow used when same-record stamp doesn't need post-save context.
• [ ] After-save flow / trigger has a recursion guard (ISCHANGED or static set).
• [ ] Entry condition scopes the automation to relevant changes only.
• [ ] Workflow Rule field updates have been migrated (or migration is planned with deactivation gating).
• [ ] One flow per object per save event (no fragmented per-team flows that all fire).
• [ ] Apex trigger uses templates/apex/TriggerHandler.cls if a trigger is the right answer.
• [ ] check_workflow_field_update_patterns.py --manifest-dir reports zero ERRORs on the branch.
• [ ] Every legacy element has a row in the mapping table, including reevaluateOnChange, targetObject and workflowTimeTriggers — or a recorded decision that it is intentionally dropped.
• [ ] Trigger-entry count per save measured before and after the cutover, and any difference accepted in writing.
• [ ] Target field checked against the "not updateable in before triggers" list before choosing before-save.
• [ ] Parity table run twice — legacy rule live, then deactivated — with identical results.
• [ ] Flow activation and rule deactivation ship in the same package.xml.
• [ ] Post-deploy field-history query returns a new row for the field.

Salesforce-Specific Gotchas

1. Before-save flows are governor-free for same-record updates. Don't re-implement same-record stamps in after-save. (See references/gotchas.md § 1.)
2. After-save flow updating the same record recurses without a guard. Default behavior; explicit guard required. (See references/gotchas.md § 2.)
3. Workflow Rule field updates are deprecated for new actions as of late 2022 — migrate or accept they're frozen. (See references/gotchas.md § 3.)
4. Formula fields are computed at read time, not stored. Reports / dashboards can sort / filter on them but at query cost. (See references/gotchas.md § 4.)
5. Before-save flows run at step 3, before-update triggers at step 4 — the order is fixed and documented, so a before trigger always sees values the before-save flow already wrote, and can overwrite them. (See references/gotchas.md § 5.)
6. Cross-object update from a flow fires the target object's automation. Plan the chain. (See references/gotchas.md § 6.)
7. Multiple flows on the same object firing on the same save event all run; ordering is not guaranteed across flows. (See references/gotchas.md § 7.)
8. ISCHANGED() is true on insert — the value changed from null. Scope the trigger setting deliberately. (See references/gotchas.md § 8.)
9. Migrate to Flow produces a draft and leaves the source rule active. Both writers run until you deactivate it. (See references/gotchas.md § 9.)
10. Retiring a field update deletes a second update-trigger pass that no Apex author wrote down; trigger behaviour changes in a deploy containing no Apex. (See references/gotchas.md § 10.)
11. reevaluateOnChange restarts every rule on the object, up to five cascades. Flow has no equivalent element. (See references/gotchas.md § 11.)
12. NextValue / PreviousValue walk the picklist's own order and have no Flow counterpart; rebuild as a transition map. (See references/gotchas.md § 12.)
13. A before-save Flow cannot write the fields the system computes during save — the workflow field update at step 11 could. (See references/gotchas.md § 13.)
14. In the pass after a field update, Trigger.old holds pre-update values, not what the user submitted. (See references/gotchas.md § 14.)
15. LookupValue only ever supported User, despite lookupValueType advertising Queue and RecordType. (See references/gotchas.md § 15.)
16. A rule with both immediate and time-dependent field updates becomes two Flows, in different save-time slots. (See references/gotchas.md § 16.)

Output Artifacts

Reference Files

Related Skills

• admin/process-automation-selection: Use for the tool-choice decision record and the save-procedure gotchas this skill cross-references rather than restates — step 11's second trigger pass, the recursive-save skip, failedMigrationToolVersion.
• apex/order-of-execution-deep-dive: Use when the question is the full 20-step sequence rather than the field-update slice of it.
• flow/workflow-rule-to-flow-migration: Use when migrating a whole rule, including alerts, tasks and outbound messages. This skill covers only the field-update action.
• admin/flow-for-admins: Use for the Flow XML surface in general — element ordering, filters vs filterFormula, status handling, activation.
• flow/record-triggered-flow-patterns: Use to build the replacement Flow once the slot is chosen.
• flow/recursion-and-re-entry-prevention: Use when the after-save variant needs a guard beyond an entry condition.
• flow/flow-time-based-patterns: Use when the source rule carried workflowTimeTriggers and the replacement needs scheduled paths.
• apex/trigger-framework: Use when the decision tree routes to Apex; canonical base at templates/apex/TriggerHandler.cls.
• flow/flow-error-notification-patterns: Use for fault handling on the after-save variant's DML.
• admin/approval-processes: Use when the field update is an approval action rather than a rule action — the same WorkflowFieldUpdate component, a different owner.
• admin/formula-fields: Use when the answer is no automation at all.
• apex/dynamic-apex: Use when the Apex variant needs Schema describe calls.

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/metadata-examples.md
• references/well-architected.md
• templates/workflow-field-update-patterns-template.md
• scripts/check_workflow_field_update_patterns.py