The Salesforce Order of Execution Explained (Modern Guide)

In plain words: The Salesforce Order of Execution is the strict, step-by-step checklist the platform follows every time a record is saved. It dictates exactly when system rules, Flows, Triggers, and automations fire. Knowing this order is the secret to preventing data from being overwritten unexpectedly and avoiding endless automation loops.

Salesforce is a massive engine handling millions of operations per second. When a user clicks "Save" on a record, the platform doesn't just instantly dump that data into the database. Instead, it runs through a highly orchestrated sequence of events.

If you don't understand this timeline, you might find your Custom Validation Rules being bypassed, or your Apex Triggers firing multiple times. Let's simplify the modern Salesforce Order of Execution.

1. Initialization & System Validation

The moment a record is submitted, Salesforce loads the original record from the database (if it's an update) and overlays the new values. Before running any custom logic, it checks the absolute basics.

• System Validation: Are required fields filled out? Are the formats correct (e.g., text isn't pasted into a number field)? Are the field values within the maximum character length?

2. Before-Save Record-Triggered Flows

This is a modern addition to the platform and incredibly fast. Before any Apex code runs, Salesforce executes Before-Save Flows (also known as Fast Field Updates).

• Because the record hasn't been saved to the database yet, these flows can update the current record's fields 10x faster than standard workflow rules.

3. Before Apex Triggers

Next, any Apex code written in a before insert or before update trigger fires. This is the traditional programmatic way to query complex related data or manipulate field values right before the save happens.

4. Custom Validation Rules

Only after the Before Flows and Before Triggers have modified the record does Salesforce run your Custom Validation Rules. This ensures that any automated changes didn't accidentally break your company's business rules.

Real-Life Example: A user leaves the "Discount" field blank. Step 2 (Before Flow) automatically sets it to 10%. Step 4 (Validation Rule) checks if "Discount > 0". Because the flow updated the value *before* the validation rule ran, the record passes the check successfully!

5. Save to Database (No Commit)

The record is now temporarily saved to the database. It is assigned a Salesforce ID (if it's a new record), but the transaction is not yet committed. If anything goes wrong in the next steps, Salesforce will completely roll back this save.

6. After Apex Triggers

Since the record now has a secure ID, after insert and after update triggers fire. This step is perfect for creating related records (like a Contact attached to a newly created Account) because you need the Account's ID to link them.

7. Execution of System Rules

Salesforce now runs through a gauntlet of standard system rules in a very specific order:

• Assignment Rules: Who should own this record?
• Auto-Response Rules: Should we email the customer a support ticket receipt?
• Workflow Rules: Legacy automations fire here.
• Escalation Rules: Does this case need to be flagged to a manager?

Developer Trap: The Recursive Loop
If Step 7 (a Workflow Rule) updates a field on the record, Salesforce actually loops back and runs Before Triggers, System Validations, and After Triggers a second time. This is a common cause of poor performance and governor limit exceptions!

8. After-Save Record-Triggered Flows & Processes

Now, modern After-Save Flows and legacy Process Builders run. Use these for heavy lifting: sending custom notifications, updating related parent or child records, or calling out to external systems.

9. Roll-Up Summary Calculations & Cross-Object Updates

If you made changes to a child record (like an Opportunity), Salesforce now calculates the Roll-Up Summary fields on the parent record (like the Account). If the Account changes as a result, the Account will go through its own Order of Execution!

10. Database Commit & Post-Commit Actions

If there were no errors, Salesforce finally hits the "Save" button permanently. The transaction is committed to the database.

• Post-Commit: Only after the commit is successful will Salesforce send out scheduled Emails, trigger Outbound Messages, and fire asynchronous operations like @future methods or Queueable Apex.

360 Card: The Ultimate Cheat Sheet
To memorize the core flow, remember this sequence:
1. System Validations
2. Before Flows
3. Before Triggers
4. Custom Validation Rules
5. Save (No Commit)
6. After Triggers
7. Rules (Assignment, Workflow, etc.)
8. After Flows
9. Commit to Database

Core Takeaway: To optimize your Salesforce org, always prefer Before-Save Flows over After-Save Flows for same-record field updates. It bypasses recursive loops and saves massive amounts of processing power.

Final Thoughts

Understanding the Order of Execution in Salesforce is what separates a good administrator or developer from a great one. By knowing exactly when your automations fire, you can build cleaner, faster, and more predictable backend architecture.