Overview
Record-Triggered Flows in Salesforce let you run automation when records are created, updated, or deleted. Two key timing options are Before-Save (Fast Field Updates) and After-Save. Choosing the right timing impacts performance, available actions, and whether you can modify the triggering record directly.
What is a Before-Save Flow?
Before-Save flows run immediately after a record is submitted but before it’s committed to the database. They are optimized for making fast updates to fields on the triggering record. Because these run in the same transaction and before DML, you can change field values directly without performing additional DML operations.
What is an After-Save Flow?
After-Save flows run after the record has been committed to the database. They are suitable for operations that require the record Id, interactions with related records, or actions that perform DML or callouts. After-save flows have access to the final state of the database and can perform more complex work.
Key Differences
1) Purpose & Use Cases
Before-Save: Use for quick field updates on the same record (e.g., auto-populate a normalized field, set a status, calculate simple values).
After-Save: Use for tasks that require the record Id or affect other records or systems (e.g., create related records, post to Chatter, send outbound messages, perform callouts, update related objects).
2) Performance
Before-save flows are more efficient because they avoid extra DML. They are executed as part of the initial save, so they’re ideal when performance matters and you only need to update fields on the triggering record.
3) Access to Record Id and Related Data
Before-save runs before the record is committed, so while the platform typically provides an Id for new records in some contexts, you should not rely on the committed state. After-save runs after commit and therefore reliably has the final record Id and can safely query or modify related records.
4) Allowed Actions
Before-save flows can only update the triggering record’s fields. They cannot create or update other records, post to chatter, send emails, or perform external callouts. After-save flows can perform these broader actions.
5) Transactional Behavior
Both flows run in the same overall transaction as the save, but before-save executes earlier. If a before-save flow fails, it prevents the save from completing. After-save flows run after commit but still participate in post-commit processing; some actions (like asynchronous paths) are recommended for long-running tasks.
Example Scenarios
Before-Save Example
Scenario: When a Lead is updated, normalize a phone number field and set a derived status.
// Record-Triggered Flow (Before Save)
Trigger: Lead - After update
Action: Assignment
lead.Normalized_Phone__c = normalize(lead.Phone)
lead.Derived_Status__c = 'Contacted'
// No extra DML required; the platform saves field changes automatically.
After-Save Example
Scenario: After an Opportunity is created, create an initial Task and notify the account owner.
// Record-Triggered Flow (After Save)
Trigger: Opportunity - After insert
Action 1: Create Records -> Task (WhoId = Opportunity.AccountId, WhatId = Opportunity.Id, Subject = 'Follow up')
Action 2: Send Email / Post to Chatter / Callout
Best Practices
Prefer Before-Save for Field Updates
If you only need to update the triggering record’s fields, use a before-save flow for better performance and lower CPU/DML usage.
Limit After-Save Work
Keep after-save flows focused and consider using asynchronous actions (Platform Events, Queueable Apex, or Scheduled Paths) for long-running tasks or callouts to avoid blocking the transaction.
Avoid Recursion
Both before- and after-save flows can cause recursive updates if they modify records that re-trigger the same flow. Implement entry conditions, a flag field, or use the $RecordPrior values to prevent infinite loops.
Limitations & Considerations
– Before-save flows can’t perform DML on other objects or call external services.
– After-save flows can be affected by record locking and governor limits when performing many DML operations.
– Some features (like certain Flow Actions or managed-package elements) may only be available in after-save timing.
Summary
Choose before-save Record-Triggered Flows when you need fast, efficient updates to the triggering record’s fields. Use after-save Record-Triggered Flows when you need the record committed, must work with related records, or must perform actions beyond updating the triggering record. Understanding these differences helps design scalable, maintainable automation in Salesforce.