The Salesforce order of execution is the fixed sequence of steps Salesforce runs every time a record is saved: system validation, before-save flows, before triggers, validation and duplicate rules, the save, after triggers, assignment and other rules, after-save flows, roll-up summaries, sharing, the commit and post-commit work such as email. Knowing it tells you which automation sees which values, and why a field "changes back" or a trigger fires twice.
This guide was first published in 2020 as "Salesforce Order of Execution". It has been rewritten for 2026 with the current 20-step sequence, how record-triggered flows fit in, and the retirement of Workflow Rules and Process Builder.
Why does the order of execution matter?
It matters because it decides which automation sees which values, so getting it wrong causes overwritten fields, blocked saves and repeated triggers. Most orgs have several kinds of automation on the same object: flows, Apex triggers, validation rules, duplicate rules and assignment rules. They don't run at the same time; they run in a set order inside one transaction. If you don't know that order you get bugs that are hard to explain: a validation rule that blocks a value a flow was meant to fix, a field update that overwrites a trigger's work, or a governor limit hit because the same record is saved three times.
The Salesforce order of execution, step by step
For an insert, update or upsert Salesforce runs 20 steps, from loading the record to post-commit email. The authoritative list is the Apex Developer Guide page Triggers and Order of Execution. For an insert, update or upsert, the server runs these steps:
| Step | What happens |
|---|---|
| 1 | Loads the original record from the database, or initialises it for an upsert. |
| 2 | Loads the new field values from the request, overwrites the old ones, and runs system validation. |
| 3 | Runs record-triggered flows configured to run before the record is saved. |
| 4 | Runs all before triggers. |
| 5 | Runs system validation again and runs custom validation rules. |
| 6 | Runs duplicate rules. A blocking duplicate rule stops the save here. |
| 7 | Saves the record to the database, but doesn't commit yet. |
| 8 | Runs all after triggers. |
| 9 | Runs assignment rules. |
| 10 | Runs auto-response rules. |
| 11 | Runs workflow rules. If they update fields, the record is updated again and before and after update triggers fire one more time. |
| 12 | Runs escalation rules. |
| 13 | Runs Process Builder processes and flows launched by workflow rules, in no guaranteed order. |
| 14 | Runs record-triggered flows configured to run after the record is saved. |
| 15 | Runs entitlement rules. |
| 16 | Updates roll-up summary fields on the parent record, which then goes through its own save. |
| 17 | Does the same for the grandparent if needed. |
| 18 | Evaluates criteria-based sharing. |
| 19 | Commits all DML operations to the database. |
| 20 | Runs post-commit logic, such as sending email and running queued asynchronous jobs. |
Two notes from the same page: during a recursive save, Salesforce skips steps 9 to 17; and in API version 53.0 and earlier, after-save record-triggered flows run after entitlement rules rather than before. The guide also warns that its diagram can fall out of sync with the text, so trust the text for your API version.
The order in plain terms
In short: prepare, before save, save and react, after save, then commit. It is easier to remember as five phases:
- Prepare. Load the record and the new values; check the basics (steps 1 to 2).
- Before save. Before-save flows, then before triggers, then validation and duplicate rules (steps 3 to 6). This is where you change the record itself cheaply.
- Save and react. The record is saved but not committed; after triggers and the older rule types run (steps 7 to 13).
- After save. After-save flows, entitlements, roll-ups and sharing (steps 14 to 18).
- Commit and follow up. Everything is committed, then email and async work run (steps 19 to 20).
Where record-triggered flows fit
Before-save flows run before Apex before triggers, and after-save flows run after after triggers. Before-save flows run before Apex before triggers, and after-save flows run after after triggers. So a value set by a before-save flow is already on the record when your before trigger sees it, and a before trigger can overwrite it. The ordering you can control:
- Between flows: Salesforce Help's run order article explains that you can give before-save and after-save flows a trigger order value from 1 to 2,000. Flows without a value run after those, ordered by activation date. The value can't move a flow outside its place in the order of execution.
- Visually: Trailhead's Flow Trigger Explorer unit shows how to see every record-triggered flow on an object, grouped by when it runs, and drag them into order with Edit Order. It notes that flows in the run-asynchronously group aren't guaranteed to run in the order listed.
- Between triggers: you can't, which is why the usual advice is one Apex trigger per object. If more than one trigger exists for the same object and event, Salesforce doesn't guarantee their order.
Workflow Rules and Process Builder in the order
Workflow Rules and Process Builder reached end of support on 31 December 2025, but any that remain still run at steps 11 and 13. Steps 11 and 13 still exist because old automation still runs. Salesforce's end-of-support article says support for Workflow Rules and Process Builder ended on 31 December 2025: existing rules keep running but get no bug fixes, and new automation belongs in Flow Builder. Moving that logic into record-triggered flows takes it out of the unordered step 13 and into steps 3 and 14, where you can control the order. That alone fixes many "random" behaviour bugs.
Common order-of-execution problems and fixes
Most problems trace back to two automations owning the same field, a re-save, or work done in the wrong phase.
| Symptom | Likely cause | Fix |
|---|---|---|
| A trigger runs twice on one save | A workflow field update re-saved the record (step 11) | Migrate the workflow rule to a before-save flow, or make the trigger check whether fields changed |
| A field you set is overwritten | A later step, such as a before trigger after a before-save flow, sets it again | Give each field one owner; set it in one place |
| A validation rule blocks a record a flow should fix | The fix runs after save, but validation runs before it (step 5) | Move the fix to a before-save flow or before trigger |
| Results change from one deploy to the next | Several triggers on one object, or unordered processes in step 13 | One trigger per object; migrate processes to ordered flows |
| Limit errors on parent updates | Roll-up summaries re-save parents and grandparents (steps 16 to 17) | Check automation on the parent object too |
| Saves feel slow to users | Heavy processing runs inside the save transaction | Move it to queued async work, which runs after the commit (step 20) |
Scenario questions on the order of execution
These are the scenarios interviewers and code reviewers ask most; each answer follows from the 20 steps above. More are in our Salesforce interview questions.
- A before-save flow and a before trigger both set the same field. Which value is saved? The trigger's, because before triggers (step 4) run after before-save flows (step 3).
- A before trigger sets a field that a validation rule checks. Does the rule see the new value? Yes. Custom validation rules run at step 5, after before triggers.
- An after-save flow changes a field that a validation rule forbids. What happens? The flow's update is a new save of the record, so that save goes through validation again and can fail.
- Can an after trigger see the record's Id on insert? Yes. The record has been saved at step 7, though not yet committed.
- A trigger sends an email, but the transaction then fails. Is the email sent? Email is post-commit logic (step 20), so it is only sent if the transaction commits.
- Why does a trigger run twice when a workflow rule is active? A workflow field update re-saves the record at step 11, and before and after update triggers fire one more time.
Design rules that follow from the order
Change the same record before save, related records after save, keep one entry point per object and push slow work to async.
- Same-record changes go before save. A before-save flow or before trigger changes the record without another save.
- Related-record changes go after save. That is when the record has an Id and is safe to reference.
- One entry point per object. Salesforce's architect guide advises using "one mechanism as your entry point into automation" and avoiding a mix of flows and Apex triggers on the same object.
- Callouts and slow work go async. They run after the commit and don't hold up the user's save.
- Test the whole chain. Run a debug log in a sandbox and check the order in which your automation actually fires.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce development services team audits automation on busy objects, consolidates triggers and flows into a predictable order, and migrates legacy Workflow Rules and Process Builder. Talk to us about an automation review.
Frequently asked questions
What is the order of execution in Salesforce?
It is the fixed sequence of steps Salesforce runs when a record is inserted, updated or upserted: system validation, before-save flows, before triggers, custom validation and duplicate rules, the uncommitted save, after triggers, assignment, auto-response, workflow and escalation rules, after-save flows, entitlement rules, roll-up summaries, sharing, the commit, and post-commit logic such as email.
Do before-save flows run before Apex before triggers?
Yes. Record-triggered flows configured to run before the record is saved run first, then all before triggers. After-save record-triggered flows run much later, after after triggers and the assignment, auto-response, workflow and escalation rules.
Do validation rules run before or after triggers?
Custom validation rules run after before-save flows and before triggers, and before the record is saved. That means a before trigger or before-save flow can set a value that a validation rule then checks.
In what order do multiple triggers on the same object run?
Salesforce doesn't guarantee an order when an object has more than one trigger for the same event. That is the main reason teams use one trigger per object with a handler class. Record-triggered flows, by contrast, can be ordered with a trigger order value from 1 to 2,000 or in Flow Trigger Explorer.
Why does my trigger run twice?
Usually because a workflow field update or another automation updated the same record. After a workflow field update, before update and after update triggers fire one more time. Automation that updates the triggering record in an after context can also cause a recursive save.