Order of Execution

When a record is saved, Salesforce performs these steps (simplified from the official documentation — always check the current *Triggers and Order of Execution* page):

Load the original record (or initialize a new one); overwrite with new field values

If from a standard UI edit page: system validation (required fields, field formats, max length)

Execute before-save record-triggered flows (fast field updates) Execute before triggers

Run most system validation again, plus custom validation rules Execute duplicate rules

Save the record to the database (not yet committed) Execute after triggers

Execute assignment rules, then auto-response rules Execute workflow rules (legacy); if field updates occur, update the record again and fire before and after update triggers one more time (custom validation rules are not re-run) Execute escalation rules

Execute processes and flows launched by processes/workflow (legacy Process Builder), in no guaranteed order Execute entitlement rules

Execute after-save record-triggered flows Recalculate roll-up summary fields and cross-object formula updates on parent/grandparent records (which run through their own save procedure) Criteria-based sharing evaluation Commit all DML to the database

Post-commit logic: send emails, enqueue async Apex (future, Queueable), publish "publish after commit" platform events, outbound messages Practical implications:

Before-save flows run before before-triggers — don't fight over the same fields in both.

A workflow field update can cause your update triggers to run twice in one transaction — design idempotent logic.

Roll-up summaries make the parent record go through its own save cycle (its triggers fire).

Async work and emails happen only if the transaction commits.

Use Flow Trigger Explorer to see the order of record-triggered flows on an object.