Explain Triggers order of execution?

The Salesforce order of execution is the fixed sequence the platform runs when a record is saved. Knowing it cold is the difference between debugging a phantom regression in an hour and chasing it for a week. Interviewers ask this verbatim; memorize the sequence.

The save pipeline (Spring ‘26)

When a record is inserted or updated via UI, API, or Apex DML, Salesforce performs this sequence:

1. Load the original record from the database (for updates) or initialize the new record (for inserts).
2. Load the new field values from the request, overwriting the old values in the in-memory record. For UI edits, system validation runs first to enforce page layout requirements and data-type checks (numeric fields, valid lookups, etc.). For non-UI sources (API, Apex), only the type and required-field checks run here.
3. Execute record-triggered Flows configured to run before the record is saved (Flow type: fast field updates).
4. Execute all before triggers.
5. Run most system validation steps again — required-field check, foreign-key checks, type checks. Custom validation rules also run here.
6. Run duplicate rules. If the rule is set to Block, the save aborts.
7. Save the record to the database, but don’t commit yet.
8. Execute all after triggers.
9. Execute assignment rules (Lead and Case).
10. Execute auto-response rules (Lead and Case).
11. Execute workflow rules. If there’s a workflow field update:
    • Update the record again, without firing triggers a second time for that field update only.
    • Re-run system validation.
    • Run before and after update triggers one more time (recursion-limited to 5).
12. Execute escalation rules (Case only).
13. Execute record-triggered Flows configured to run after the record is saved.
14. Execute Processes (Process Builder) and Flow Builder flows that run on save.
15. Execute entitlement rules.
16. If the record contains roll-up summary fields or is part of a cross-object workflow, perform the calculations and parent updates. Updates to the parent re-enter the parent’s save sequence at step 1.
17. Execute Criteria-Based Sharing recalculation.
18. Commit all DML operations to the database.
19. Execute post-commit logic, such as sending emails and firing async jobs (@future, Queueable, Batch).

Key implications

• Validation runs after before triggers, not before. A before trigger that sets a default value can satisfy a required-field validation that would otherwise have blocked the save.
• @future and Queueable see the committed database state. They run after step 18 — every DML before them is persisted.
• Workflow field updates re-fire before/after triggers, but only for the affected field updates. This is the source of most “why is my trigger running twice?” bugs.
• Roll-up summary updates re-enter the parent’s save pipeline at step 1. A grandparent update may fire its own triggers.

A common gotcha

A before update trigger that sets Status__c = 'Approved' and a validation rule that says Status__c != 'Approved' OR Approval_Notes__c != '' will pass — because the trigger ran first and the field is now 'Approved'. Flip the logic in the rule (or the trigger) and the save breaks. The order of execution explains why.

Common interview follow-ups

• Where does Flow fit in? — Two places. Record-triggered “before-save” flows run at step 3 (before before triggers). After-save flows run at step 13 (after after triggers, before post-commit).
• What happens if a before trigger modifies a field that has a validation rule? — Validation runs against the modified value (step 5). A trigger can fix data the user gave you.
• Does Salesforce guarantee trigger order between two triggers on the same object? — No — that’s exactly why “one trigger per object” is a best practice.

Verified against: Apex Developer Guide — Triggers and Order of Execution. Last reviewed 2026-05-17 for Spring ‘26.