Save Order of Execution

Save Order of Execution in Salesforce – Complete Guide for Platform Developer 1 Exam

Why Is Save Order of Execution Important?

Understanding the Save Order of Execution is one of the most critical topics for the Salesforce Platform Developer 1 exam and for real-world Salesforce development. When a record is saved in Salesforce — whether through the UI, an API call, Apex code, or any other mechanism — Salesforce follows a very specific sequence of steps before the record is finally committed to the database. If you do not understand this order, you may encounter unexpected behavior such as triggers firing at the wrong time, validation rules blocking updates you didn't anticipate, workflow rules overwriting field values, or recursive trigger execution. Mastering this topic helps you:

• Debug complex automation issues
• Design automation solutions that work harmoniously together
• Avoid infinite loops and recursion
• Answer 2–5 exam questions correctly (this topic appears frequently)

What Is Save Order of Execution?

The Save Order of Execution is the predetermined sequence of operations that Salesforce performs every time a record is inserted, updated, or upserted. It dictates exactly when each type of automation (triggers, workflow rules, process builders, flows, validation rules, etc.) fires relative to the others. Think of it as a pipeline: the record enters at one end, passes through multiple processing stages, and is committed to the database at the other end.

How Does It Work? – The Full Sequence

Below is the detailed order of operations that Salesforce executes when a record is saved:

1. Original Record Loaded from Database (or Initialized for New Records)
If the record already exists, Salesforce loads it from the database. For new records, a new record object is initialized with default field values.

2. New Field Values Overwrite Old Values
The system overwrites the old field values with the new values provided by the user or the calling code. However, the record has not been saved to the database yet. System fields like CreatedDate and CreatedById are also set at this point for new records.

3. System Validation Rules Run
Salesforce runs system-level validations. These are built-in checks such as:
• Required fields at the page layout level
• Field format validations (e.g., valid email format)
• Maximum field length checks
• Unique field and foreign key checks
Note: Custom validation rules do NOT run at this step.

4. Before Triggers Execute
All before triggers fire at this point. Before triggers are commonly used to:
• Set or modify field values on the record before it is saved (no DML needed)
• Validate data and add errors using addError()
Because the record has not yet been committed, you can change field values directly on the Trigger.new records without performing an explicit DML update.

5. Custom Validation Rules Run
After before triggers complete, Salesforce evaluates custom validation rules. This is a very important point to remember: custom validation rules run AFTER before triggers. This means that any field values set in a before trigger will be evaluated by validation rules. If a validation rule fails, the entire transaction is rolled back.

6. Duplicate Rules Run
Salesforce checks duplicate rules to identify and potentially block duplicate records.

7. Record Saved to Database (But Not Yet Committed)
The record is saved to the database in a temporary state. At this point, the record receives an ID (if it is a new insert). However, the transaction has not been committed — it can still be rolled back.

8. After Triggers Execute
All after triggers fire at this point. After triggers are commonly used to:
• Access system-generated field values (like Id or auto-number fields)
• Make changes to other (related) records
• Enqueue asynchronous operations
Note: In after triggers, the records in Trigger.new are read-only. You cannot modify them directly. To update related records, you must perform DML on separate sObject instances.

9. Assignment Rules Execute
Lead and Case assignment rules are evaluated and applied.

10. Auto-Response Rules Execute
Auto-response rules for leads and cases are evaluated and email responses are queued.

11. Workflow Rules Execute
Workflow rules are evaluated. If a workflow rule has field update actions, those field updates are applied to the record. Important: If workflow field updates modify the record, the system saves the record to the database again and re-fires before and after triggers one more time. However, the system will not re-evaluate workflow rules a second time (preventing infinite loops at this level).

12. Processes (Process Builder) and Flows Execute
Record-triggered processes (Process Builder) and autolaunched flows (both before-save and after-save record-triggered flows) execute. Note: In newer Salesforce releases, before-save record-triggered flows actually run before the record is saved (between steps 4 and 5), and after-save record-triggered flows run in this phase. Always check the latest Salesforce documentation for the most current order.

13. Escalation Rules Execute
Escalation rules for cases are evaluated.

14. Roll-Up Summary Fields Are Calculated
If the record is a detail in a master-detail relationship, roll-up summary fields on the parent record are recalculated. If the parent record is updated due to a roll-up summary recalculation, the save order of execution runs again on the parent record.

15. Cross-Object Formula Fields Are Recalculated
Any cross-object formula fields that reference the saved record are updated.

16. Criteria-Based Sharing Rules Are Evaluated
Sharing rules based on criteria are re-evaluated for the record.

17. DML Operation Is Committed to the Database
The entire transaction is committed. All changes become permanent. If any step above fails, the entire transaction is rolled back — nothing is saved.

18. Post-Commit Logic Executes
After the commit, the following occur:
• Email sends (from workflow rules, email alerts, or Apex) are dispatched
• Asynchronous Apex jobs (future methods, queueable, batch) are queued for execution
• Outbound messages are sent


Key Points to Remember

• Before triggers fire BEFORE custom validation rules. This means you can set required fields in a before trigger, and validation rules will see those values.

• After triggers fire AFTER the record is saved but BEFORE the transaction is committed. The record has an ID at this point, but a rollback can still undo everything.

• Workflow field updates cause before and after triggers to fire again. This is a common source of unexpected behavior and a frequent exam question topic.

• Records in Trigger.new are read-only in after triggers. You must query or create new sObject instances to update related records.

• Roll-up summary recalculations can trigger the save order on parent records.

• Emails and async operations happen AFTER commit. If the transaction is rolled back, these never execute.

• Before-save record-triggered flows run before the record is saved to the database and before after triggers. They are similar to before triggers in that you can modify the triggering record without DML.


Exam Tips: Answering Questions on Save Order of Execution

Tip 1: Memorize the High-Level Order
You don't need every micro-step, but you must know this core sequence:
System Validations → Before Triggers → Custom Validation Rules → Record Saved → After Triggers → Assignment Rules → Auto-Response Rules → Workflow Rules (with possible re-trigger) → Processes/Flows → Escalation Rules → Roll-Up Summaries → Commit → Post-Commit (Emails, Async)

Tip 2: Focus on the Relationship Between Before Triggers and Validation Rules
Many exam questions test whether you know that before triggers run before custom validation rules. A common scenario: "A developer sets a field value in a before trigger. Will the validation rule see the updated value?" The answer is yes.

Tip 3: Understand Workflow Field Update Re-Triggering
If a question describes unexpected trigger behavior occurring twice, check if there is a workflow field update involved. Workflow field updates cause triggers to re-fire, which is a classic exam trap.

Tip 4: Know What Happens in Before vs. After Triggers
Questions often ask where to place logic. Use before triggers to modify the current record's fields (no DML needed). Use after triggers to update related records or when you need the record's ID.

Tip 5: Remember That Trigger.new Is Read-Only in After Triggers
If a question shows code that modifies Trigger.new in an after trigger, it will cause a runtime error. This is a very common distractor in exam answers.

Tip 6: Emails Are Sent After Commit
If a question asks when emails are sent or whether they are sent if a transaction fails, remember: emails are queued and only sent after the transaction commits successfully. If the transaction rolls back, no emails are sent.

Tip 7: Watch for Questions About Recursion
Questions may describe a scenario where an after trigger updates a record, causing the same trigger to fire again. Understand that this can lead to infinite loops and that developers should use static variables or other recursion-prevention patterns.

Tip 8: Before-Save Flows vs. Before Triggers
Salesforce recommends using before-save record-triggered flows for simple field updates because they execute before the record is saved, similar to before triggers but without Apex code. Know that before-save flows run in the same phase as before triggers but before them in the latest order of execution updates.

Tip 9: Process of Elimination
When you see a question about order of execution, eliminate answers that place events in the wrong order. For example, any answer that says custom validation rules run before before triggers is incorrect. Any answer that says emails are sent before the commit is incorrect.

Tip 10: Practice with Scenarios
The exam loves scenario-based questions. Practice by tracing through a scenario step by step: "A user updates a record. There is a before trigger, a validation rule, a workflow rule with a field update, and an after trigger. In what order do these execute?" Walk through the save order mentally to arrive at the correct answer.


Summary

The Save Order of Execution is a foundational concept in Salesforce development. It governs how and when every piece of automation interacts with a record during a save operation. For the Platform Developer 1 exam, focus on the relative order of before triggers, validation rules, after triggers, workflow rules (and their re-triggering behavior), and the commit/post-commit distinction. By mastering this sequence, you will not only answer exam questions confidently but also build more reliable and predictable Salesforce applications.