Order of Execution

Why Order of Execution Matters

When a user clicks Save on a record, or a record is created or updated via the API, a data loader, or another automation, Salesforce does not simply write the data to the database. It runs the record through a long, strictly sequenced series of checks and automations before the change is finally committed. This sequence is called the Order of Execution.

Understanding it is critical for an Advanced Administrator because:
• It explains why an automation did or did not fire, and why a field value looked different from what was expected.
• It determines whether a validation rule can block a change made by a workflow field update, a flow, or an Apex trigger.
• It is the root cause of many puzzling behaviours such as triggers firing twice, roll-up summaries not matching, or emails being sent even though a later step failed.
• It is a heavily tested topic in the Advanced Process Automation section of the Salesforce Certified Advanced Administrator exam. Scenario questions frequently hinge on knowing which step runs first.

What Is the Order of Execution?

The Order of Execution is the documented sequence of events Salesforce performs on the server every time a record is inserted, updated, or upserted. It applies regardless of whether the change originates from the standard UI, Lightning Experience, the API, Data Loader, or another piece of automation performing DML. It is not the order in which you created your automations; it is a fixed, platform-defined order.

Key principle: every step runs in order, and the record is saved but not committed part-way through. Nothing is permanent until the final commit step. If any step fails (for example a validation rule or an Apex exception), the entire transaction rolls back and nothing is saved.

How It Works: The Full Sequence

Below is the current Salesforce-documented order. Memorise the broad phases first, then the details.

Phase 1 – Load and Initial Validation
1. Salesforce loads the original record from the database (or initialises a new record for an insert/upsert).
2. It loads the new field values from the request and overwrites the old values. It then runs system validation. If the request comes from a standard UI edit page, this includes layout-specific rules (required fields on the page layout, field formats, maximum field lengths, valid foreign keys). Requests from the API or other sources skip the layout-specific checks but still enforce field-level required values and data types. Custom validation rules are NOT run at this step.

Phase 2 – Before-Save Automation
3. Executes record-triggered flows configured to run before the record is saved (Fast Field Updates / before-save flows).
4. Executes all before triggers (Apex before insert / before update).

Phase 3 – Validation and Duplicate Checking
5. Runs most system validation again (required fields non-null, field formats) and runs all custom validation rules. The only system validation not repeated is enforcement of layout-specific rules.
6. Executes duplicate rules. If a duplicate rule with the Block action identifies a match, the record is not saved and no further steps run.

Phase 4 – Save (Not Commit) and After-Save Triggers
7. Saves the record to the database, but does not commit yet. At this point the record now has an ID, which is why after triggers can reference it.
8. Executes all after triggers (Apex after insert / after update).

Phase 5 – Classic Rule-Based Automation
9. Executes assignment rules (Leads and Cases).
10. Executes auto-response rules (Leads and Cases).
11. Executes workflow rules. If a workflow rule performs a field update, the record is updated again, system validation runs again, and before update and after update triggers fire one more time (and only one more time). Custom validation rules, duplicate rules, flows, processes, and escalation rules are not run again.
12. Executes escalation rules (Cases).

Phase 6 – Flow-Based Automation
13. Executes processes (Process Builder), flows launched by processes, and flows launched by workflow rules. The order among these is not guaranteed. When a process or flow performs DML, the affected record goes through the entire save procedure again.
14. Executes record-triggered flows configured to run after the record is saved (Actions and Related Records).
15. Executes entitlement rules.

Phase 7 – Related Record Updates
16. If the record contains a roll-up summary field or is part of a cross-object workflow, Salesforce performs the calculation and updates the parent record. The parent goes through its own save procedure.
17. If the parent record is updated and the grandparent record contains a roll-up summary field or is part of a cross-object workflow, the grandparent is also updated and goes through its own save procedure.
18. Executes criteria-based sharing evaluation.

Phase 8 – Commit and Post-Commit
19. Commits all DML operations to the database.
20. Executes post-commit logic: sending emails, executing enqueued asynchronous Apex (future methods, queueable jobs), and running asynchronous paths (scheduled paths) in record-triggered flows.

Important Behaviours and Nuances

• Validation rules run before workflow field updates. A workflow field update can therefore set a value that would normally violate a validation rule. This is a classic exam scenario.
• Before-save flows and before triggers run before validation rules. Any value they set is checked by validation rules, so a before-save flow cannot bypass validation.
• After-save flows run after validation rules. If an after-save flow updates the triggering record, that update is a new DML operation and goes through the full order of execution again, including validation rules.
• Workflow field updates re-fire triggers only once. Even if multiple workflow rules update fields, before and after update triggers fire just one additional time.
• Order of multiple triggers on the same object is not guaranteed. Best practice is one trigger per object.
• Order of multiple processes or flows is not guaranteed unless you use the Trigger Order setting on record-triggered flows (Flow Trigger Explorer). The exam may test your knowledge that you should consolidate automation into a single flow or use trigger order to control sequence.
• Emails are post-commit. If the transaction fails, no email is sent, even if the email alert step was reached earlier.
• Roll-up summaries happen after the child record is saved. A validation rule on the parent checking a roll-up summary value may fire during the parent save procedure triggered by the child save.
• Everything rolls back on failure. If a validation rule fails on the grandparent during a roll-up recalculation, the original child save also fails.
• Before-save flows are the fastest way to update fields on the same record because they avoid an extra DML operation and do not trigger the save procedure again.

Memory Aid

Try this phrase to anchor the main sequence: Load – Before Flow – Before Trigger – Validate – Dupe – Save – After Trigger – Assign – Auto-respond – Workflow – Escalate – Process – After Flow – Entitlement – Roll-up – Sharing – Commit – Email.

Or remember the four big questions: Before or after save? Before or after validation? Before or after commit? Does it cause a re-save? Most exam questions can be answered by placing the automations in the scenario against these four checkpoints.

How to Answer Order of Execution Questions in the Exam

Exam questions rarely ask you to recite the list. Instead they present a scenario and ask what the outcome will be, or which automation tool to use. Use this method:

Step 1 – Identify every automation in the scenario. List out the validation rules, triggers, workflow rules, processes, before-save flows, after-save flows, roll-ups, and emails mentioned.
Step 2 – Place each one on the timeline. Put them in order using the sequence above.
Step 3 – Ask whether a value was set before or after validation. This decides most questions about why a validation rule did or did not block a change.
Step 4 – Check for re-entry. Did a workflow field update, process, or after-save flow modify the record? If so, triggers fire again and the record may go through the order again.
Step 5 – Check for commit dependency. Emails and asynchronous logic only happen after commit, so a failure anywhere stops them.
Step 6 – Eliminate answers that contradict the fixed order. Distractors often claim that validation runs after workflow, that flows run before triggers, or that emails are sent even when the save fails.

Exam Tips: Answering Questions on Order of Execution

• Tip 1: If a question says a workflow field update set a value that should have violated a validation rule, the correct explanation is that validation rules run (step 5) before workflow rules (step 11). To enforce the rule, move the logic into a before-save flow or a validation-safe approach.
• Tip 2: If a question asks for the most efficient way to update a field on the same record being saved, the answer is a before-save record-triggered flow, because it runs before validation and before the record is saved, with no extra DML.
• Tip 3: If a question asks how to update related records or send an email, the answer is an after-save record-triggered flow, because the record ID exists only after step 7.
• Tip 4: When a scenario mentions a trigger firing twice, look for a workflow field update. It re-fires before and after update triggers exactly one more time.
• Tip 5: When asked why an email was not sent after a failed save, remember emails are post-commit; a rollback cancels them.
• Tip 6: When asked to control the order of several flows on the same object, choose Flow Trigger Explorer / trigger order or consolidate into one flow. Do not pick an answer that relies on creation date or alphabetical order.
• Tip 7: Duplicate rules run after validation rules and before the record is saved. If a duplicate rule blocks, nothing downstream runs.
• Tip 8: Assignment rules run before auto-response rules, and both run before workflow rules. Escalation rules run after workflow rules.
• Tip 9: Roll-up summary recalculation and parent record saves happen late (steps 16–17), after all automations on the child, so a parent validation rule can still cause the child save to fail.
• Tip 10: Watch for the word committed. The record is saved at step 7 but committed only at step 19. Answers that confuse the two are usually wrong.
• Tip 11: Layout-specific required fields are enforced only for standard UI saves. API and Data Loader inserts bypass page-layout requirements but not field-level requirements. This is a common trap.
• Tip 12: Read the question for the origin of the save (UI, API, flow, Apex). The origin changes which system validations apply at step 2.

Quick Practice Scenario

A validation rule prevents Close Date from being in the past. A workflow rule sets Close Date to a past date when Stage is Closed Lost. Users report the validation rule does not block the change. Why?

Answer: Validation rules execute at step 5, before workflow rules at step 11. The workflow field update re-runs system validation and triggers but not custom validation rules, so the past date is saved. The fix is to move the date logic into a before-save flow (which runs before validation) or to adjust the validation rule design.

Summary

The Order of Execution is the backbone of Salesforce automation behaviour. Learn the sequence, understand the four checkpoints (before save, before validation, before commit, re-entry), and practise mapping scenario automations onto the timeline. With that approach, Order of Execution questions on the Advanced Administrator exam become predictable and highly answerable.