8.3 Save Order of Execution

8.3 Save Order of Execution

Quick Answer: When a record is saved, Salesforce runs a documented order of execution: system validation → before-save Flows → before triggers → custom validation rules → duplicate rules → save (pre-commit) → after triggers → assignment rules → auto-response rules → workflow (and related legacy automation) → escalation/entitlement steps → after-save Flows → roll-up summary parent updates → sharing recalculation → commit → post-commit work (emails, async). Before-trigger field changes affect later validation; after work can re-enter parts of the sequence. Always verify details against the official Apex Developer Guide order-of-execution article.

Order of execution (OOE) questions separate candidates who memorize trigger syntax from those who can predict what runs when a field changes. You do not need every micro-step recited word-for-word, but you must reason about relative order and recursive side effects.

Why Order of Execution Matters

A single user click or API update can fire:

• Declarative automation (Flow, validation rules, assignment rules)
• Apex triggers
• Legacy Workflow Rules / Process Builder still present in many orgs
• Roll-up summaries that update parents
• Email and async post-commit logic

If a before-save Flow sets Status = 'Closed', a before trigger can read that value. If a before trigger sets a field that breaks a validation rule, the save fails after the trigger ran. If an after trigger updates a parent, the parent’s entire save order may run—multiplying SOQL/DML toward governors.

Exam-Focused Ordered List

The platform publishes a longer, definitive list. For Platform Developer I reasoning, internalize this critical path (simplified, exam-oriented):

1. Load original record / initialize new record; apply request field values
2. System validation — required fields, field types, max length; on UI edits also restricted picklists and other layout-level checks as documented
3. Before-save record-triggered Flows (Fast Field Updates) — same-record field changes only
4. Before Apex triggers — can modify Trigger.new; addError can fail the save
5. Custom validation rules (and validation still applicable at this stage)
6. Duplicate rules
7. Save record to the database (not yet committed)
8. After Apex triggers
9. Assignment rules
10. Auto-response rules
11. Workflow rules — field updates may update the record again and re-fire a subset of the save sequence (before/after triggers can run again for those updates, with documented limitations such as not re-running the full workflow stack endlessly)
12. Processes / legacy Process Builder and related legacy paths still listed in official docs where applicable
13. Escalation rules
14. Entitlement rules
15. After-save record-triggered Flows (Actions and Related Records)
16. Roll-up summary fields recalculate; if parent values change, parent record goes through save order
17. Criteria-based sharing rule evaluation / recalculation as documented
18. Commit all DML operations for the transaction
19. Post-commit logic — email sends, async paths (@future, Queueable enqueued work starts after commit success), and similar

Source of truth: Salesforce updates wording and inserts steps (especially Flow-related) over time. When in doubt for production design, open the current Apex Developer Guide: Triggers and Order of Execution. For the exam, relative relationships below matter more than the exact integer index of a minor step.

Relative Placements You Must Not Confuse

Before Trigger Field Changes (Classic Exam Pattern)

// before update on Opportunity
for (Opportunity o : Trigger.new) {
    if (o.Amount != null && o.Amount >= 100000) {
        o.Priority__c = 'High';
    }
}

Because this runs before custom validation rules:

• A validation rule that requires Priority__c when Amount ≥ 100000 will see the stamped value and can pass
• A validation rule that forbids Priority__c = High under some other condition can fail the save even though the trigger “succeeded” in memory
• Before-save Flow that already set Priority__c may be overwritten by the trigger if both write the same field—last writer before validation wins among those early steps in their relative order (Flow first, then before trigger)

Exam tip: If asked what a validation rule evaluates, include values set by before-save Flow and before triggers, not only the raw UI input.

Recursive Updates from Automation

Workflow field updates

When a Workflow Rule field update changes the record, Salesforce performs an additional update cycle. Documented behavior includes re-running before and after triggers once for those updates, with constraints so the platform does not infinitely re-run the entire workflow engine. Exam stems still expect: “workflow field update → triggers can fire again.”

After-save Flow / Process / after trigger updating the same record

Updating the same record again starts another save path (additional before/after work, more governors). Prefer before-save Flow or before trigger field edits to avoid a second update when only same-record stamps are needed.

Static recursion guards

When after-trigger logic must update related records that update the original object, use static flags/sets (8.2 / 8.4) so the second entry is controlled.

Formula Fields and Recalculation

Formula fields are calculated when read; they are not stored DML targets. In OOE scenarios:

• Formulas that reference fields changed in before context reflect those values when later logic reads them in the same transaction as documented for formula evaluation timing
• Cross-object formulas and roll-ups interact with parent/child saves—roll-up summaries are stored and can drive parent OOE when children change
• Do not write a before trigger that “assigns” a formula field—the field is read-only

Cascading Through Roll-Ups and Parents

Child insert/update/delete that changes a roll-up summary causes the parent to be updated and to run through save automation. One Opportunity line change can fire Account triggers, Account Flows, and Account validation. Bulk child loads multiply parent saves—design selective parent automation and bulk-safe parent triggers.

Common Exam Scenarios

Scenario A — “Which runs first?”
Before-save Flow vs before trigger → Flow first.
Before trigger vs validation rule → before trigger first.
After trigger vs after-save Flow → after trigger first (Flow later in the list).

Scenario B — “Why did validation fail after my trigger set the field?”
Either the trigger ran in after context (too late for that save’s field write without re-update), or another step overwrote the value, or the validation references a different field still invalid.

Scenario C — “Why did the trigger run twice?”
Workflow field update, Process/Flow updating the record, roll-up parent path, or explicit DML in after context causing re-entry.

Scenario D — “User edited one field; many automations fired.”
OOE runs the full applicable stack when entry criteria of each engine match—not only the field the user touched. Tight entry conditions on Flow and change-detection in triggers reduce waste.

Scenario E — “Assignment rule overwrote OwnerId set in a trigger.”
Assignment rules run after after triggers. Setting OwnerId in after trigger can still lose to assignment rules depending on configuration; owner stamping often needs careful placement (before vs after, or “do not reassign” options on the operation). Read stems for which tool sets owner last.

Practical Design Rules from OOE

1. Same-record stamps → before-save Flow or before trigger
2. Related DML → after trigger or after-save Flow; accept re-entry risk and bulkify
3. Never assume peer trigger order; use one trigger per object
4. Count parent roll-up cascades in governor budgets
5. When debugging “wrong field value,” walk OOE writers in order rather than only reading your class
6. Confirm ambiguous new product steps against the official order-of-execution document

Mental Model for Snippets

When a question shows stacked automation, draw a quick timeline:

input → system validation → before Flow → before trigger → validation → save → after trigger → assignment/auto-response/workflow → after Flow → roll-up parent OOE → commit → async/email

Ask: At which step is my field written? At which step is it read? Does any later step overwrite it? Does any step update another record that restarts the timeline?

That timeline—not memorizing every bullet alone—is what earns points on Process Automation and Logic items involving triggers.