When a record is inserted or updated, Salesforce runs a fixed pipeline. Knowing this order is what lets you predict why automations fire (or don't) when they should.
The simplified order — there are about 20 steps but the ones that matter to admins are:
- System Validation — required fields, max field length, foreign key validity.
- Apex `before` triggers — run code that needs to mutate the record before save.
- Custom Validation Rules — your declarative rules. If any returns FALSE, save is rejected here.
- Before-save record-triggered Flows (Fast Field Updates) — modern, fastest place to update fields on the same record.
- Database save (commit-1) — the record is persisted, but the transaction is not yet committed.
- Apex `after` triggers — code that needs the record's Id (assigned at step 5).
- Assignment Rules — Lead/Case assignment rules execute.
- Auto-Response Rules — Lead/Case auto-response.
- After-save Record-Triggered Flows — declarative automation that runs after the save.
- Workflow Rules — legacy, fire field updates and outbound messages.
- Processes — Process Builder logic (legacy).
- If a workflow field update happened, before/after triggers and validation rules fire AGAIN on those fields (recursion guard).
- Escalation Rules (Cases).
- Entitlement Rules (Cases).
- Roll-Up Summary recalculation on parent records.
- Sharing rules evaluation.
- Database commit (commit-2) — transaction now durable.
- Post-commit logic: Outbound Messages, async (queueable, future, batch), Platform Events that publish on commit.
Practical takeaways:
- Before-save flows are the cheapest place to update fields on the saving record.
- Validation rules fire twice if a workflow field update changes a referenced field.
- After triggers are where you do anything that needs the record's Id.
- Outbound Messages and async Apex run only after commit-2 — they don't see the record's intermediate state.