Before-Save Versus After-Save Record-Triggered Flows

Why This Topic Matters
Record-triggered flows are the cornerstone of modern declarative automation in Salesforce. With Workflow Rules and Process Builder retired, the Advanced Administrator exam expects you to know how to choose the correct trigger timing for any business requirement. The before-save versus after-save decision affects performance, governor limit consumption, what actions are available, and whether your automation is even possible. Exam questions in the Advanced Process Automation domain frequently present a scenario and ask which flow configuration is best, so understanding the distinction is essential both for passing the exam and for building efficient, scalable automation in real orgs.

What It Is
A record-triggered flow is a flow that launches automatically when a record is created, updated, or deleted. When you configure the trigger, you choose when the flow runs relative to the database save operation:

1. Before-save (Fast Field Update): Runs before the record is committed to the database. The flow can update fields on the triggering record only, using the $Record global variable, without a separate Update Records element and without an additional DML operation. In Flow Builder this appears as Optimize the Flow for: Fast Field Updates.

2. After-save (Actions and Related Records): Runs after the record has been saved and has an ID. The flow can create, update, or delete related records, send emails, post to Chatter, call Apex, invoke subflows, send custom notifications, and schedule paths. In Flow Builder this appears as Optimize the Flow for: Actions and Related Records.

There is also a third option, Run Asynchronously (an asynchronous path within an after-save flow), and the Scheduled Paths feature, both of which are only available for after-save flows.

How It Works: Order of Execution
Understanding where each type fits in the Salesforce save order is critical:

1. Record is loaded and system validation runs (required fields, field formats).
2. Before-save record-triggered flows run.
3. Before triggers (Apex) run.
4. Custom validation rules, duplicate rules, and other system validations run.
5. Record is saved to the database (not yet committed).
6. After triggers (Apex) run.
7. Assignment rules, auto-response rules, workflow rules (legacy).
8. Escalation rules, entitlement rules.
9. After-save record-triggered flows run.
10. Roll-up summary fields and cross-object workflow on parent records.
11. Criteria-based sharing evaluation.
12. Commit to the database.
13. Post-commit logic (emails, asynchronous paths, outbound messages).

Key insight: because before-save flows run before validation rules, a field value set by a before-save flow will be checked by validation rules. Because they run before the record is written, field changes made by a before-save flow do not trigger an additional save, meaning no extra DML, no re-firing of triggers, and dramatically better performance.

Key Differences at a Glance

Before-Save
- Purpose: Update fields on the same record.
- Record ID available on create: No (record has not been inserted yet).
- Available elements: Assignment, Decision, Get Records, Loop, and a limited set of logic elements. No Create, Update, Delete, Action, Subflow, or Email elements.
- DML cost: None for updating the triggering record (you assign values to $Record directly).
- Performance: Approximately 10x faster than after-save for same-record updates.
- Triggers: Create, Update, Create or Update, Delete (before-delete added in recent releases).
- Scheduled paths: Not available.
- Asynchronous path: Not available.
- Re-evaluation: Does not cause the record to be saved again.

After-Save
- Purpose: Act on related records, send notifications, call external systems, run scheduled logic.
- Record ID available: Yes.
- Available elements: All, including Create Records, Update Records, Delete Records, Action, Subflow, Email Alert, Post to Chatter, Submit for Approval, custom notifications.
- DML cost: Updating the triggering record requires an Update Records element, which is an additional DML and causes the record to go through the save order again (recursion risk).
- Scheduled paths: Available (time-based actions, replacing time-dependent workflow actions).
- Asynchronous path: Available for callouts and heavy processing after commit.
- Entry conditions: Can be set to run only when the record meets conditions and, optionally, only when it is updated to meet them.

Decision Framework
Ask yourself three questions when choosing:

1. Am I only changing fields on the record that triggered the flow? If yes, use before-save. This is the single most important rule.
2. Do I need to create, update, or delete other records, send emails, post to Chatter, submit for approval, call Apex, or schedule actions in the future? If yes, use after-save.
3. Do I need the record ID of a newly created record (for example, to populate a lookup on a child record or build a URL)? If yes, use after-save.

Common real-world examples:
- Setting a default value, formatting a phone number, copying a value from a parent record to a child record field on save: before-save.
- Creating a follow-up Task when an Opportunity closes: after-save.
- Sending an email alert when a Case priority changes: after-save.
- Updating all Contacts when an Account address changes: after-save (related records).
- Reminding the owner three days before Close Date: after-save with a scheduled path.
- Making an external callout when a record is created: after-save with an asynchronous path.

Best Practices and Nuances
- Use a Get Records element in a before-save flow to look up related data (such as parent values) and then assign results to $Record fields. This is allowed because Get Records is a query, not DML.
- Use entry conditions on both types to limit when the flow fires, improving performance and avoiding unnecessary executions.
- Use the Only when a record is updated to meet the condition requirements option to mimic the legacy ISCHANGED behavior and prevent repeat firing.
- Use $Record__Prior to compare old and new values (available in both before-save and after-save update flows).
- Salesforce recommends one before-save and one after-save flow per object per trigger type (or a few well-organized ones) and using flow trigger order to control execution sequence when multiple flows exist.
- Avoid updating the triggering record in an after-save flow when a before-save flow could do the job; this prevents recursion and saves limits.
- Before-save flows cannot be debugged with the same breadth of actions, but you can test with sample records in Flow Builder debug mode.

Exam Tips: Answering Questions on Before-Save Versus After-Save Record-Triggered Flows

1. Look for the words same record versus related records. If the scenario only mentions populating, defaulting, or modifying fields on the record being saved, the answer is almost always before-save (Fast Field Updates). If it mentions child records, parent records, other objects, emails, tasks, or notifications, the answer is after-save.

2. Performance keywords point to before-save. When a question emphasizes high volume, data loads, efficiency, governor limits, or avoiding extra DML, choose before-save for same-record updates. Salesforce documentation explicitly states that before-save flows are significantly faster.

3. Time-based requirements mean after-save with a scheduled path. Phrases such as three days after, one hour before, or when a date is reached require a scheduled path, which exists only in after-save flows.

4. Callouts and external integrations mean after-save with an asynchronous path. Remember that callouts cannot occur in the same transaction before commit; the asynchronous path runs after the transaction commits.

5. Know the order of execution. A question may ask why a validation rule still fired on a value set by a flow, or why a before-save update did not re-trigger another flow. Before-save runs before validation rules and before Apex before-triggers; after-save runs after Apex after-triggers and after legacy workflow rules.

6. Watch for the record ID trap. If a scenario on record creation requires the new record's ID (for example, creating a child record linked to it), before-save cannot work because the ID does not exist yet.

7. Eliminate distractors involving retired tools. If answer choices include Workflow Rules or Process Builder, these are generally incorrect for new automation because Salesforce recommends Flow. Choose the flow option that matches the requirement.

8. Recognize Get Records is allowed in before-save. A distractor may claim you cannot access related data in a before-save flow. You can query related records with Get Records; you simply cannot create, update, or delete them.

9. Delete triggers. If the scenario involves acting when a record is deleted (for example, preventing orphaned data or logging deletions), know that record-triggered flows support delete triggers and that related-record actions on delete require the appropriate configuration.

10. Read for the best answer, not just a working one. Many exam questions have two technically functional answers. The correct one is the most efficient and aligned with Salesforce best practices: before-save for same-record field updates, after-save only when needed, entry conditions to limit firing, and one flow per object per trigger where possible.

Quick Recall Summary
- Before-save = Fast Field Updates = same record only = no DML = fastest = runs before validation rules.
- After-save = Actions and Related Records = anything else = record ID available = scheduled and asynchronous paths = runs late in the save order.
- When in doubt: if you only touch $Record fields, go before-save; otherwise go after-save.