The Salesforce order of execution is the fixed sequence of steps Salesforce runs every time a record is saved. For record-triggered flows the headline answer is short: a before-save flow runs first, ahead of every before Apex trigger and every custom validation rule, and an after-save flow runs later, after the record has been written to the database and after the after triggers and workflow rules, but before the transaction commits.
That answer settles most arguments about which automation wins. It does not settle all of them, because one save can pass through a dozen automations, and an update made in one step can send the record back through the whole sequence. This guide walks through the full 20-step order in plain English, shows where each kind of flow sits, and gives you a method for mapping what runs on your own objects. If you want help with that mapping, the Cirra AI Salesforce Admin MCP Server reads the metadata on an object from the AI client you already use.
The short answer: where record-triggered flows run
A record-triggered flow runs at one of three points in a save. The step numbers below come from Salesforce's own list, which follows in full in the next section.
| Flow timing | Step | What surrounds it |
|---|---|---|
| Before-save (Fast Field Updates) | 3 | Runs before all before Apex triggers (step 4) and before custom validation rules (step 5). |
| After-save (Actions and Related Records) | 14 | Runs after the record is saved without a commit (step 7), after the after triggers (step 8) and workflow rules (step 11), and before roll-up summary recalculation (step 16) and the commit (step 19). |
| Asynchronous path | 20 | Runs as post-commit logic, after the transaction has committed. |
One version note: in API version 53.0 and earlier, after-save flows run after entitlement rules instead of before them. If you maintain older flows, check which API version they were saved with.
The full order of execution, in plain English
Salesforce publishes the sequence in the Apex Developer Guide, on the page Triggers and Order of Execution. The version below follows the page for API version 68.0 (Winter '27), reworded and grouped into five stages. Salesforce edits the list from time to time, so confirm it against the page for your own release before you rely on a detail.
Stage 1: load the record and check the request (steps 1 and 2)
Salesforce loads the existing record from the database, or prepares a blank one for an upsert.- It overwrites the old values with the new values from the request and runs a first round of validation. A standard UI edit checks layout rules, required fields, formats and field length. Other sources, such as Apex or the API, check foreign keys, formats, maximum lengths and restricted picklists.
Stage 2: before-save automation (steps 3 to 6)
Before-save record-triggered flows run.- Before Apex triggers run.
- Most system validation runs again, and custom validation rules run. Layout-specific rules are not rerun.
- Duplicate rules run. If a rule matches and uses the block action, the record is not saved and none of the later steps run.
Stage 3: save without committing (steps 7 and 8)
Salesforce saves the record to the database but does not commit it.- After Apex triggers run.
Stage 4: after-save automation (steps 9 to 15)
Assignment rules run.- Auto-response rules run.
- Workflow rules run. If a workflow rule has a field update, the record is updated again, system validation runs again, and the before update and after update triggers fire one more time. Custom validation rules, flows, duplicate rules, Process Builder processes and escalation rules are not rerun in that second pass.
- Escalation rules run.
- Process Builder processes and flows launched from workflow rules run, in no guaranteed order.
- After-save record-triggered flows run.
- Entitlement rules run.
Stage 5: roll-ups, sharing and commit (steps 16 to 20)
If the record has a roll-up summary field, or belongs to a cross-object workflow, Salesforce recalculates and updates the parent record, which goes through the save procedure.- If that update changed the parent and the grandparent has a roll-up summary field, the grandparent is recalculated and saved the same way.
- Criteria-based sharing is evaluated.
- Salesforce commits all DML operations to the database.
- Post-commit logic runs, in no particular order. This includes sending email, queued Apex jobs and future methods, and asynchronous paths in record-triggered flows.
What the order means for your flows
Before-save flows run ahead of nearly everything
Because a before-save flow runs at step 3, the values it sets are what the before triggers and the validation rules see. That is useful. A flow can fill in a default date and a validation rule can then check the result. It also means a before Apex trigger at step 4 runs after your flow and can overwrite what the flow wrote. If both touch the same field, the trigger wins.
After-save flows run once the record exists
By step 14 the record has been written, so it has an ID and you can create related records. The flow runs after the workflow rules, which means it sees any field they changed. It runs before roll-up summary fields are recalculated at step 16, so a flow that reads a roll-up on a parent record in the same save sees the old value.
A flow that updates its own record starts the save over
Salesforce's documentation notes that when a process or flow executes a DML operation, the affected record goes through the save procedure. An after-save flow that updates the record that triggered it sends that record back through before-save flows, triggers and validation. Tight entry conditions, such as running only when a field changes to a specific value, are what keep that from looping. Our guide to Salesforce Flow best practices shows how to set them.
Asynchronous paths run after the commit
Asynchronous paths run at step 20, when the record is already committed. They are a good home for work that does not need to block the save, such as a callout or a notification. A failure there cannot undo the save that started it, so give those paths their own error handling.
How to control the order of several flows on one object
When an object has more than one record-triggered flow for the same event, use Flow Trigger Explorer. According to Salesforce Help, it shows the record-triggered flows for an object and a chosen create, update or delete event, including the before-save and after-save flows and their asynchronous paths. Salesforce Ben explains how to open it: from Flows in Setup, or from the Start element of a record-triggered flow, where an Open Flow Trigger Explorer link appears.
In the explorer, Edit Order lets you drag flows into a new sequence, which changes each flow's Trigger Order value. Trigger Order accepts a number from 1 to 2,000, and the Salesforce Admins blog recommends spacing the numbers by 10s or 100s so you can slot in new flows later. Four limits are worth knowing:
- Trigger Order ranks flows that run in the same slot. Before-save flows all run at step 3, so you cannot place an after-save flow ahead of a before-save flow, or place any flow ahead of or behind an Apex trigger.
- Standard flows from Salesforce show in the sequence, but you cannot reorder them.
- Record-triggered flows created from a flow template do not appear in Flow Trigger Explorer.
- Subflows called from inside a record-triggered flow do not appear either.
Two design patterns are common. Some teams keep one record-triggered flow per object and trigger type and route everything through decisions. Others keep several small flows and set Trigger Order on each one. Both work if the team documents the choice and applies it everywhere.
Five conflicts the order of execution explains
These are typical situations. The sequence is fixed, so the cause is usually easy to find once you know where each automation sits.
- Two writers on one field. A before-save flow sets Priority to High and a before Apex trigger sets it to Medium. The trigger runs later, so Medium is saved. Give each field a single owner.
- A validation rule blocks a value your automation wrote. The rule runs at step 5, after the before-save flow, so it checks the flow's output and not only what the user typed. Test with the flow active and look at which field the error names.
- A stale roll-up. An after-save flow on a child record reads the parent's roll-up summary field and gets the previous total, because the roll-up recalculates at step 16. Read the child records directly, or move the logic to a flow that runs on the parent.
- A trigger that fires twice. An old workflow rule with a field update causes the before update and after update triggers to run one more time at step 11. Apex that is not written for repeat runs can create duplicate records or double-count. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, and Salesforce Ben reports that bugs in them will no longer be fixed. That is a good reason to migrate them to Flow.
- Automation that never starts. A duplicate rule with the block action stops the save at step 6. No after-save flow, after trigger or workflow rule runs for that record.
A method for mapping what runs on an object
Pick one object where users report odd behavior and work through these steps in a sandbox.
- Choose the object and the event: create, update or delete.
- Open Flow Trigger Explorer for that pair. Note each flow, its timing group and its Trigger Order.
- In Object Manager, list the object's Apex triggers and validation rules. In Setup, check for any remaining Workflow Rules and Process Builder processes that target the object.
- Write the sequence in order of execution, with one line per automation and the fields it writes. A short list is enough:
Opportunity, on update (example names) Step 3 Before-save flow Opportunity_BeforeSave_SetNextStepDate writes NextStepDate__c Step 4 Before trigger OpportunityTrigger writes Description Step 5 Validation rule Require_Loss_Reason Step 14 After-save flow Opportunity_AfterSave_CreateRenewalTask creates a Task - Look for four patterns: two writers on one field, a validation rule on a field an earlier step writes, an after-save flow that updates its own triggering record, and a Workflow Rule field update that fires an Apex trigger a second time.
If a flow fails once you know the order, our step-by-step method for debugging a Salesforce flow covers the error email, the debug panel and fault paths.
How Cirra AI can help you map and fix automation order
Doing this audit by hand means opening several Setup screens for every object. When you connect your AI client to your org through Cirra AI, you can ask for the map in plain English. A prompt like this is a good start:
List the active flows, Apex triggers, validation rules and workflow rules on Opportunity.
Put them in order of execution and tell me which fields each one writes.Cirra AI reads the metadata on the object and your AI client lays the results out in the order you asked for, so you start from a draft map instead of a blank page. Check the draft against Flow Trigger Explorer before you act on it. From there, Cirra AI can edit the logic of an existing flow, or review an Apex trigger for issues and suggest specific fixes.
Cirra AI runs as the connected user, within that user's Salesforce permissions, and documents each change. Make changes in a sandbox first, then deploy to production through your usual process. Cirra AI supports Salesforce Enterprise Edition and up, and the Free plan includes 100 credits so you can try it on a real org.
Ready to try it? Choose Start Free Trial, or Book a Demo to walk through your own objects with us.
Frequently asked questions
What is the order of execution in Salesforce?
The order of execution is the sequence of steps Salesforce follows every time a record is saved. It starts by loading the record and validating the request, runs before-save automation, saves the record without committing, runs after-save automation, recalculates roll-up summary fields, evaluates sharing, commits the transaction, and finishes with post-commit logic such as email and asynchronous jobs.
When do record-triggered flows run in the order of execution?
Before-save record-triggered flows run at step 3, before any before Apex trigger. After-save record-triggered flows run at step 14, after the after triggers and workflow rules and before the commit. Asynchronous paths run after the commit as post-commit logic.
Do before-save flows run before validation rules?
Yes. A before-save flow runs at step 3 and custom validation rules run at step 5. The validation rule checks the values the flow has already set.
Do flows run before or after Apex triggers?
Both, depending on the flow. A before-save flow runs before the before Apex triggers, and an after-save flow runs after the after Apex triggers. Trigger Order on a flow cannot move it across an Apex trigger.
How do I set the order of multiple record-triggered flows?
Use Flow Trigger Explorer. Choose the object and the event, select Edit Order, and drag the flows into the sequence you want. This sets each flow's Trigger Order value, which accepts a number from 1 to 2,000. It only orders flows that run in the same slot, such as several before-save flows.
Do validation rules run again after an after-save flow updates a record?
If the flow updates the record that triggered it, that update goes through the save procedure again, so the record is validated again. Entry conditions that run the flow only when a field changes keep the update from repeating.
Do Workflow Rules and Process Builder still run?
Existing Workflow Rules and Process Builder automations still sit in the order of execution, at steps 11 and 13, but Salesforce ended support for them on December 31, 2025 and no longer fixes bugs in them. Moving that logic to Flow is the recommended path.
