Study guide
6.2 Record-Triggered Flows: Fast Field Updates vs. Actions
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
6.2 Record-Triggered Flows: Fast Field Updates vs. Actions
Key Takeaways Explain This Topic AI
Fast Field Updates (Before-Save) execute prior to database commits, updating fields directly on $Record in memory with zero DML consumption and up to 10x faster execution.
Immediate Actions and Related Records flows run after the initial save but before transaction commit. They can use the new record ID and perform related-record operations; asynchronous paths run later.
Before-save flows cannot execute actions, call subflows, create or delete records, or access $Record.Id during record creation.
Run Asynchronously paths execute in a new transaction after a successful commit. Design for applicable Flow limits, queue delay, retry behavior, and separate failure handling.
Flow Trigger Order enables administrators to assign deterministic execution priorities (1 to 2,000) across multiple record-triggered flows on the same object.
Last updated: October 2026
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:
- Fast Field Updates (Before-Save Trigger)
- 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:
Salesforce loads the record and submitted values and performs initial system checks.
Before-save record-triggered flows modify the in-memory triggering record.
Before Apex triggers run, followed by system checks and custom validation rules .
Duplicate rules run. The record is saved and receives an ID on insert, but the transaction is still uncommitted.
After Apex triggers , assignment rules, auto-response rules, and legacy workflow processing run.
Escalation rules, legacy processes and their invoked flows, and immediate after-save record-triggered flows execute, followed by applicable entitlement processing.
Roll-up calculations and related parent save procedures run. Salesforce then commits the transaction.
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.
Tip
The Before-Save Golden Rule: Whenever a business requirement asks to set, calculate, default, or validate field values on the same record that triggered the flow, always choose Fast Field Updates.
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
Architectural Dimension Fast Field Updates (Before-Save) Actions and Related Records (After-Save) Run Asynchronously Path
Execution Point Before Apex/custom validation and initial save After initial save, before commit Separate background queue after commit
Modifies Triggering Record Via In-memory $Record assignment Explicit Update Records DML Explicit Update Records DML
- DML Statement Consumption 0 DML statements Consumes DML per data element Consumes DML in async context
- $Record.Id Available on Create? No ( null ) Yes (initial save; not yet committed) Yes
- Create / Update Related Records? No Yes Yes
- Execute Actions & Subflows? No Yes Yes
External HTTP Callouts? No Not directly in the save transaction; invoking Apex does not bypass callout restrictions Yes (Native HTTP Callout)
Governor Limit Context Synchronous (100 SOQL / 150 DML) Synchronous (100 SOQL / 150 DML) Fresh Flow transaction budget; check applicable limits
Primary Use Case Same-record calculations, data cleansing Related record updates, emails, tasks Heavy processing, external REST callouts
Best Practices & Common Exam Traps
Important
Never Use After-Save to Update $Record Fields Alone: If a requirement only modifies fields on the triggering record, using an after-save flow is an anti-pattern. It executes an unnecessary DML statement, consumes CPU time, and risks recursion. Always configure Fast Field Updates.
Note
Formula Fields vs. Fast Field Updates: While formula fields calculate values dynamically at read time, they cannot store static historical values, be indexed for search as easily, or serve as external IDs. Use Fast Field Updates when field values must be persisted or indexed upon record save.
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 .