Salesforce Order of Execution Made Simple: What Really Happens in After-Save Flows?

If you’ve spent any time building automation in Salesforce, you’ve probably heard this Golden Rule:

"Always update fields on the triggering record using a Before-Save Flow!"

It sounds simple enough, but why is this rule so heavily emphasized? What actually happens under the hood when you update a record inside an After-Save Flow instead? Does Salesforce rewind everything back to Step 1?

Let’s lift the hood on the Salesforce Order of Execution, break down what happens during a record update in plain English, and look at how to build faster, cleaner automation.

The Basics: The Salesforce "Assembly Line"

Whenever a user clicks Save on a record, Salesforce doesn't just write the data to a database and call it a day. It passes the record through a strict, multi-step assembly line called the Order of Execution.

Here is a simplified look at what happens in order:

1. Loads the record and applies your new field values. 
2. System Checks: Verifies required fields and basic data formats.
3. Before-Save Flows: Updates fields on the record in memory before touching the database.
4. Before Apex Triggers: Executes custom Apex code meant to run prior to the save.
5. Validation Rules: Evaluates your custom business rules (e.g., "Account Phone cannot be blank").
6. Saves to Database: Writes the record to the database (saved, but not finalized yet).
7. After Apex Triggers: Executes post-save custom code.
8. Workflows & Assignment Rules: Runs legacy workflow rules or lead/case routing.
9. After-Save Flows: Executes flows built for related record updates or external actions.
10. Roll-Up Summaries: Recalculates totals on parent records.
11. Sharing Evaluation: Recalculates who gets access to view the record.
12. Database Commit: Finalizes the transaction, sends queued emails, and finishes!
    
    
    

The Big Question: What Happens in Step 9?

A common myth among Salesforce beginners is that reaching Step 9 (After-Save Flows) automatically rewinds the entire transaction back to Step 1.

The short answer: No, it does not.

If your After-Save Flow simply completes its work or updates a different record (like updating child Contacts under a parent Account), the main record moves smoothly along to Step 10 (Roll-Up Summaries).

However, a massive shift occurs if your After-Save Flow uses an Update Records element to modify the very same record that started the process.

The "Double Loop" Problem

Let's walk through a real-world scenario:

1. A user updates the Account Name field and clicks Save.

2. An After-Save Flow triggers. Its job is to calculate a value and update the Phone Number field on the same Account record.

Because the record was already written to the database back in Step 6, modifying the record again in Step 9 forces Salesforce to issue an explicit DML Update command.

Salesforce is now forced to pause the primary save process and spawn a nested, secondary save process inside the first one!

[PRIMARY SAVE PROCESS] User updates Account Name
  │
  ├── Steps 1 through 8 run normally
  │
  └── Step 9: After-Save Flow updates Phone Number on the SAME record
       │
       ├──► [NESTED SAVE PROCESS SPAWNED]
       │      ├── Step 1: Loads the record again
       │      ├── Step 3: Before-Save Flows run again
       │      ├── Step 4: Before Triggers run again
       │      ├── Step 5: Validation Rules run again
       │      ├── Step 7: After Triggers run again
       │      └── Step 9: After-Save Flows run again (High risk of infinite loops!)
       │
       └──► [PRIMARY SAVE PROCESS RESUMES] ──> Finishes Steps 10 through 12

Why is this secondary process so dangerous?

• Doubled Resource Limits: Validation rules, triggers, and automations execute twice for a single user click. This consumes twice as much CPU time and governor limits.

• Slower User Experience: The page takes noticeably longer to save because Salesforce is running through two complete save lifecycles.

• Recursion & Crash Risks: If your flow entry conditions aren't carefully restricted, Cycle 2 can accidentally trigger Cycle 3, causing the system to crash with a CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY error.

Before-Save vs. After-Save: Cheat Sheet

To keep your org running fast and error-free, follow this simple framework when choosing a flow type:

Your Goal	Choose This Flow Type	Why?
Update fields on the SAME record	Before-Save Flow (Fast Field Updates)	1 Save Cycle. Updates happen in memory before the record is saved to the database. No nested loops!
Update RELATED records or perform outside actions	After-Save Flow (Actions & Related Records)	Necessary for external actions. Required when you need the record's ID, need to update child records, or need to send emails.

Summary Checklist for Admins & Developers

1. Rule of Thumb: If a Flow modifies $Record (the triggering record), move that logic into a Before-Save Flow.

2. Use Entry Criteria: In After-Save Flows, always use precise filter conditions (such as IsChanged checks) so the flow won't execute unnecessarily during nested updates.

3. Protect Your Org's Health: Minimizing database hits keeps page load times fast, prevents CPU timeout errors, and makes your automation scalable for years to come.