6.2 Record-Triggered Flows: Fast Field Updates vs. Actions

Record-Triggered Flows: Fast Field Updates vs. Actions

Record-Triggered Flows are the declarative workhorses of the Salesforce platform. Whenever a record is created, updated, or deleted, a Record-Triggered Flow can execute business logic automatically. However, not all record triggers execute at the same point in the transaction lifecycle.

When creating a Record-Triggered Flow, Flow Builder presents two primary optimization paths:

1. Fast Field Updates (Before-Save Trigger)
2. Actions and Related Records (After-Save Trigger)

Selecting the correct trigger path is one of the most critical architectural decisions an app builder can make. It dictates execution performance, governor limit consumption, re-entrancy behavior, and available flow elements.

---

Validation Rules in the Platform Order of Execution

Use the relative order to reason about a save. The full sequence includes conditional stages and repeat-save behavior; this is the essential App Builder path:

1. Salesforce loads the record and submitted values and performs initial system checks.
2. Before-save record-triggered flows modify the in-memory triggering record.
3. Before Apex triggers run, followed by system checks and custom validation rules.
4. Duplicate rules run. The record is saved and receives an ID on insert, but the transaction is still uncommitted.
5. After Apex triggers, assignment rules, auto-response rules, and legacy workflow processing run.
6. Escalation rules, legacy processes and their invoked flows, and immediate after-save record-triggered flows execute, followed by applicable entitlement processing.
7. Roll-up calculations and related parent save procedures run. Salesforce then commits the transaction.
8. Post-commit processing includes queued asynchronous Flow paths and email delivery.

A before-save flow can populate a value before a custom validation rule evaluates it, but do not depend on it to rescue an input rejected by an earlier system-required-field check. Immediate after-save flows are not post-commit jobs: a later error can still roll back their work.

Legacy workflow field updates have special repeat-save behavior. They rerun before/after Apex triggers without rerunning custom validation rules in that workflow update cycle. Approval field updates also do not automatically pass through custom validation rules. Distinguish these from ordinary Flow Update Records operations, which use normal record-save behavior. Test the actual combination of automation in a sandbox.

---

Fast Field Updates (Before-Save Flows): Core Mechanics

Fast Field Updates flows execute before before-Apex triggers and custom validation, before the record is written to the database disk.

How It Works

When a Fast Field Updates flow triggers, Salesforce passes the in-flight record into the global variable $Record. When you update field values on $Record (using an Assignment element or setting field values in an Update Records element), the platform modifies the record in memory. When the flow completes, the modified $Record is written to the database during the later initial save.

Avoiding an Extra Save Cycle

Because the field modifications occur in memory prior to the initial database write, Fast Field Updates:

• Consume Zero DML Statements: Modifying $Record does not count toward the 150 DML statement governor limit.
• Prevent Recursive Execution: In contrast to legacy workflow field updates or poorly written after-save flows, Fast Field Updates do not re-launch the entire 20-step Order of Execution.
• Lower Save-Cycle Overhead: In-memory assignments avoid an extra same-record DML operation. Salesforce documents up to tenfold gains compared with equivalent record-change processes, rather than a universal speed ratio for all automation.

Strict Boundaries of Before-Save Flows

Because the record has not yet been committed to disk, strict platform boundaries apply:

• No Record ID on Insert: During record creation (Record is Created), $Record.Id is null because the database has not generated the ID yet.
• Cannot Modify Other Records: You cannot create, update, or delete related records (no parent or child record DML).
• No Actions Allowed: Flow Builder hides all action elements. You cannot send Email Alerts, post to Chatter, call Outbound Messages, or invoke Subflows.
• No Scheduled or Asynchronous Paths: Before-save flows must complete synchronously within the immediate save transaction.

---

Actions and Related Records (After-Save Flows): Core Mechanics

Actions and Related Records flows execute after the initial save and relevant rules, before final commit, after the triggering record has been written to the database disk and assigned an ID.

Capabilities

• Access to Record ID: Full access to $Record.Id during both Create and Update operations.
• Cross-Object DML: Can create child records (e.g., auto-generating an Onboarding Task or Contract when an Opportunity is Closed Won), update parent records (e.g., updating Account status based on Case severity), or modify unrelated objects.
• Platform Actions: Can execute standard and custom actions: Send Email Alert, Post to Chatter, Submit for Approval, Call Invocable Apex, or invoke Subflows.
• Scheduled Paths: Can schedule actions relative to a date/time field on the record (e.g., 30 days before Contract Expiration Date, or 2 hours after Case Creation).

The Cost of After-Save Execution

Updating records in an after-save flow requires an explicit Update Records DML element, consuming 1 DML statement. Furthermore, updating the triggering record in an after-save flow causes Salesforce to re-evaluate the Order of Execution, potentially triggering recursion loops and degrading performance.

---

Asynchronous Execution: Run Asynchronously Path

In high-volume or integration-heavy environments, executing heavy logic synchronously within a user's save transaction can result in CPU timeouts (Apex CPU time limit exceeded) or degraded UI responsiveness.

Flow Builder allows after-save Record-Triggered Flows to define a Run Asynchronously path:

• Isolated Transaction: The asynchronous path runs in a separate background thread after the original transaction commits, when queue resources are available.
• Fresh Governor Limits: The path receives a fresh transaction budget. Do not substitute Batch/Queueable Apex limits for Flow limits; the Flow documentation lists 100 SOQL queries, 150 DML statements, 50,000 queried rows, 10,000 DML rows, and 10,000 ms CPU per transaction.
• External Integrations: Allows callouts in a separate transaction after the initial save. Make the callout before that new transaction performs DML; an asynchronous path does not bypass uncommitted-work rules.
• Mixed DML Prevention: Resolves MIXED_DML_OPERATION errors by isolating setup object modifications (e.g., User, UserRole) from standard object modifications (e.g., Account, Contact).

---

Flow Trigger Order: Deterministic Execution

In complex enterprise orgs, multiple Record-Triggered Flows often exist on the same object for the same trigger event (e.g., three separate after-save flows on Opportunity when updated).

Prior to Flow Trigger Order, Salesforce executed multiple flows on the same object in non-deterministic order, creating unpredictable race conditions.

Configuring Flow Trigger Order

• Trigger Order Value: An integer value between 1 and 2,000 specified in the flow's Version Settings.
• Ascending Execution: Flows execute in ascending numerical order: an Opportunity flow with Trigger Order 10 executes before an Opportunity flow with Trigger Order 20.
• Unordered Flows: Flows ordered 1–1,000 run first, then unordered flows by activation date, then flows ordered 1,001–2,000. Equal numeric orders use API-name alphabetical order. This does not order asynchronous paths.
• Architectural Best Practice: Assign trigger orders in increments of 10 or 100 (e.g., 10, 20, 30 or 100, 200, 300). This preserves numerical gaps, allowing developers to insert intermediate flows in the future without renumbering existing production flows.

---

Architectural Comparison: Fast Field Updates vs. Actions vs. Asynchronous

---

Best Practices & Common Exam Traps

Common Exam Traps

• Trap 1: Attempting to read $Record.Id during Before-Save Create. If a flow logic branch checks $Record.Id IS NULL FALSE inside a before-save flow on record creation, it will fail because the ID does not exist until Step 6.
• Trap 2: Expecting Before-Save flows to send email notifications. Email alert actions are prohibited in before-save flows. If a notification must be sent, the flow must be configured for Actions and Related Records.
• Trap 3: Assuming Trigger Order coordinates Apex and Flow. Flow Trigger Order (1–2,000) only controls the execution sequence of flows relative to other flows on the same object. It does not dictate whether Apex triggers run before or after flows.

Official Source Check

Checked October 19, 2026: Flow trigger order; Flow transaction limits.