Salesforce order of execution
The Salesforce order of execution is the sequence the platform follows every time a record is inserted, updated or upserted: before-save flows, before triggers, validation, the save itself, after triggers, legacy workflow, after-save flows, roll-ups and sharing, then the commit and post-commit work. Knowing it is how you predict what a save really does.
Before the record is saved
Salesforce first loads the existing record (or initialises a new one) and overwrites its values with those from the request. It then runs system validation, which depends on where the request comes from: an edit page in the UI checks layout rules, required fields, formats and lengths, while an Apex or API call checks foreign keys, formats, lengths and restricted picklists.
Next come before-save record-triggered flows, then all before Apex triggers. System validation runs again, together with the org's custom validation rules, and then duplicate rules. A duplicate rule set to block stops the save at that point: nothing after it runs.
Save, after triggers and the rest of the automation
The record is then saved to the database but not yet committed, and all after triggers run. Assignment rules, auto-response rules and workflow rules follow. If a workflow field update changes the record, the before-update and after-update triggers fire one more time — and only once more — while custom validation rules are not re-run.
Escalation rules, Process Builder processes and flows launched by workflow rules come next, followed by after-save record-triggered flows and entitlement rules. If the record feeds a roll-up summary or cross-object workflow, the parent record goes through its own save. Criteria-based sharing is evaluated, and finally every DML operation in the transaction is committed.
After the commit
Post-commit logic runs once the data is committed, in no particular order: sending email, executing enqueued asynchronous Apex such as queueable jobs and future methods, and the asynchronous paths of record-triggered flows.
What the order does not guarantee
Salesforce documents several gaps. When more than one trigger is defined on the same object for the same event, their relative order is not guaranteed. Processes and workflow-launched flows also run without a guaranteed order between them. Salesforce's architect guidance recommends one automation entry point per object and advises against mixing Flow and Apex triggers as entry points for the same object — the fewer independent pieces react to the same save, the easier the sequence is to reason about.
How aprity helps
aprity reads an org's metadata read-only and builds a per-object execution graph: the triggers, flows and business rules that run on each save event, grouped by event and computed deterministically from the dependency graph. Each business rule links to the component it was read from, so a reviewer can check what fires on a save without opening every trigger and flow by hand.
Related terms
- Before-save vs after-save flow — The two optimisations of a record-triggered flow: Fast Field Updates run before the save, Actions and Related Records run after it.
- Apex trigger — Apex code that runs automatically before or after records of an object are inserted, updated, deleted or undeleted.
- Validation rule — A formula that blocks a record from being saved and shows an error message whenever the formula evaluates to true.
- Record-triggered flow — A Flow that Salesforce launches automatically when a record of a given object is created, updated or deleted.
Sources
Official Salesforce documentation this entry was checked against. Platform behaviour changes between releases; the linked page is the reference.