Salesforce Order of Execution: Complete 2026 Guide for Admins & Developers
A Validation Rule says the record should fail.
A Trigger says it should pass.
A Flow changes the field again.
Who wins?
The answer is the Salesforce Order of Execution — and it can make or break every automation you build.
This article breaks down all 18 commonly referenced execution stages that Salesforce runs through when a record is saved — step by step, with code examples, governor limit implications, a hands-on exercise, architect best practices, and interview trap questions you can apply immediately.
What Is the Order of Execution?
When you click Save on a record, Salesforce does not simply write that data to the database. It runs through a carefully ordered series of steps — executing system logic, your custom logic, automation, and validation — before committing anything permanently.
Understanding this sequence is the difference between:
Building automations that work predictably every time
Debugging mysterious failures at 11 PM in production
This is also one of the most frequently tested topics in Salesforce certification exams and technical interviews.
Important: Not All Stages Run Every Time
These are 18 commonly referenced execution phases. Several only fire under specific conditions:
Assignment Rules — Lead and Case only, and only when explicitly enabled
Auto-Response Rules — Lead and Case creation only
Escalation Rules — Case only, based on time criteria
Entitlement Rules — only when Entitlement Management is active
Workflow Rules — only in orgs with active Workflow Rules
Process Builder — only in orgs that have not yet migrated to Flow
In a modern, well-maintained Salesforce org in 2026, the stages that typically run are:
✅ System Validation
✅ Before-Save Flow (if configured)
✅ Before Trigger (if configured)
✅ Validation Rules (if configured)
✅ Database Save
✅ After Trigger (if configured)
✅ After-Save Flow (if configured)
✅ Roll-Up Summary Evaluation (if applicable)
✅ Database Commit
The 18 Commonly Referenced Execution Stages
Critical Correction: Before-Save Flow Position
⚠️ This is one of the most commonly misunderstood points — and many articles still get it wrong.
Before-Save Record-Triggered Flows do NOT run together with After-Save Flows.
Before-Save Flows execute BEFORE the record is saved — at Stage 02, before Before Triggers.
Correct sequence for modern Salesforce orgs:
BEFORE SAVE (Stages 01–07):
Stage 01: System Validation
Stage 02: Before-Save Flow ← runs HERE
Stage 03: Before Trigger
Stage 04: System Validation (second pass)
Stage 05: Validation Rules
Stage 06: Duplicate Rules
Stage 07: Record saved to database (ID assigned)
AFTER SAVE (Stages 08–18):
Stage 08: After Trigger
Stage 15: After-Save Flow ← runs HERE
Stage 18: Commit to database ✅
Why does this matter?
Your Validation Rule at Stage 05 validates the final values after both the Before-Save Flow and the Before Trigger have run — not the original user input. Design your automation with this in mind.
Stage-by-Stage Breakdown
Stage 01 — System Validation
Before any custom logic runs, Salesforce validates:
Required fields have values
Field data types are correct
Field length limits are not exceeded
Layout-specific required fields
If this fails, the user sees an error immediately and nothing else runs.
Stage 02 — Before-Save Record-Triggered Flows
Before-Save Flows execute before the record is saved to the database.
They are optimized for updating the triggering record and should be kept lightweight.
What Before-Save Flows are designed for:
Setting default field values
Updating fields on the triggering record without a DML operation
Running conditional field logic based on simple criteria
Keep Before-Save Flows focused. Avoid building heavy logic here — for complex business rules, Apex Triggers or After-Save Flows are better suited.
Stage 03 — Before Triggers
Before Triggers run after Before-Save Flows but still before the database save.
What you can do:
Modify field values on the record
Validate data using addError()
Set default values using complex Apex logic
⚠️ On field conflicts between Before-Save Flows and Before Triggers:
Avoid multiple automations updating the same field. Even though Before-Save Flows and Before Triggers have a defined execution sequence, conflicting ownership creates maintenance and debugging problems that compound over time.
The principle is simple: assign each field to exactly one automation tool and document it.
Example — Before Trigger:
apex
trigger ContactBeforeSave on Contact (before insert, before update) {
for (Contact c : Trigger.new) {
if (c.Phone != null) {
c.Phone = PhoneFormatter.format(c.Phone);
}
}
}
Stage 04 — System Validation (Second Pass)
Salesforce re-runs system validation after Before Triggers.
If your Before Trigger accidentally sets a required field to null, this step catches it and stops the save.
Stage 05 — Custom Validation Rules
One of the most misunderstood facts in all of Salesforce:
Validation Rules run AFTER Before-Save Flows AND Before Triggers.
Your Validation Rule validates the FINAL field values set by all before-save automation — not the original user input.
Use this intentionally. A Before-Save Flow can default a field, and a Validation Rule can then check that defaulted value.
Stage 06 — Duplicate Rules
Duplicate Rules compare the record being saved against records already committed in the Salesforce database.
Depending on your rule configuration:
Alert — user sees a warning but can still save
Block — save is prevented entirely
Note: Matching behavior and results can vary depending on your duplicate rule configuration and transaction context.
Stage 07 — Record Saved to Database (Not Committed)
The record is written to the database and receives an ID — but the transaction has NOT been committed.
Critical distinctions:
The record has been assigned an Id and is available to subsequent execution steps within the transaction
The transaction CAN still be rolled back if a later stage fails
Everything before Stage 18 is part of one atomic transaction
Stage 08 — After Triggers
After Triggers run after the record is in the database (with an ID) but before the final commit.
What you can do:
Query related records
Perform DML on OTHER objects
Publish Platform Events
Enqueue Queueable Apex for asynchronous processing
Invoke @future methods for asynchronous operations
⚠️ Callouts from Triggers:
Triggers cannot perform direct HTTP callouts. The correct pattern is:
After Trigger
↓
Enqueue Queueable Apex (@future or Queueable with AllowsCallouts)
↓
Callout executes asynchronously in a separate transaction
The HTTP callout does not happen immediately after commit — it executes asynchronously in a separate transaction, subject to its own governor limits and queue processing.
⚠️ Recursion prevention — use Set, not static Boolean:
Avoid this:
apex
private static Boolean hasRun = false; // Fails in bulk — blocks all records after first
Use this instead:
apex
public class TriggerHandler {
private static Set<Id> processedIds = new Set<Id>();
public static Boolean hasProcessed(Id recordId) {
if (processedIds.contains(recordId)) return true;
processedIds.add(recordId);
return false;
}
}
Better yet — use an established Trigger Framework (FFLIB, Nebula Trigger Framework) that handles bulkification, recursion, and separation of concerns automatically.
Stages 09–14 — Rules & Legacy Automation
Stage 09 — Assignment Rules (Lead/Case only) Automatically assigns records to users or queues. Only fires on insert, or when the user explicitly enables "Assign using active assignment rules."
Stage 10 — Auto-Response Rules (Lead/Case only) Sends automated email responses. Common for web-to-case and web-to-lead.
Stage 11 — Workflow Rules ⚠️ Migrate to Flow Builder. If a Workflow Field Update fires, it can re-run Before and After Triggers — adding recursion risk and consuming additional governor limit resources.
Stage 12 — Escalation Rules (Case only) Time-based Case escalation based on SLA criteria.
Stage 13 — Workflow Field Updates ⚠️ Field updates from Workflow Rules can re-trigger Stages 03–08. Always use a Set-based recursion guard.
Stage 14 — Process Builder Process Builder is no longer being enhanced and Salesforce recommends migrating all Processes to Flow Builder. Many organisations still actively run Process Builder today — if yours does, plan your migration roadmap now.
Stage 15 — After-Save Record-Triggered Flows
After-Save Record-Triggered Flows execute after the record is saved and typically after After Triggers within the transaction.
However, Workflow Rules, Process Builder, Flow-triggered updates, and recursive save cycles can make the overall execution path more complex in legacy orgs.
What After-Save Flows are designed for:
Creating and updating related records
Calling Subflows and invocable Apex actions
Sending email alerts and notifications
Launching additional automation chains
After-Save Flows are the modern, supported replacement for Process Builder and most Workflow Rules.
Stage 16 — Entitlement Rules (Case only)
Applies entitlement milestones — response time, resolution time, and SLA targets. Only fires when Entitlement Management is enabled.
Stage 17 — Roll-Up Summary Evaluation & Parent Record Recalculation
If the saved record is a child in a Master-Detail relationship, Salesforce evaluates and recalculates Roll-Up Summary fields on the parent record.
⚠️ This is more complex than it appears:
The parent record recalculation can itself trigger additional saves
Parent saves re-evaluate their own Order of Execution
Deep Roll-Up Summary chains (child → parent → grandparent) can cascade significantly
In complex orgs, this stage can have major performance and governor limit implications at scale
Stage 18 — Criteria-Based Sharing + Commit
Sharing Rules are evaluated and applied. Then the entire transaction is committed permanently to the database.
All-or-nothing rule: Any unhandled exception at any stage rolls back the entire transaction. No partial commits. No partial saves.
"Modern Salesforce Org — Most Common Execution Path (2026)"
USER CLICKS SAVE
↓
[01] System Validation
↓
[02] Before-Save Flow
↓
[03] Before Trigger
↓
[04] System Validation (second pass)
↓
[05] Validation Rules
↓
[06] Duplicate Rules
↓
[07] Record Saved (ID Assigned, Not Committed)
↓
[08] After Trigger
↓
[15] After-Save Flow
↓
[17] Roll-Up Summary Evaluation & Parent Recalculation (if applicable)
↓
[18] Criteria-Based Sharing Evaluation
↓
COMMIT TO DATABASE ✅
⚠️ Important Notes About This Diagram
• This is the most common execution path in a modern Salesforce org (2026), not the complete Order of Execution.
• Additional stages such as Assignment Rules, Auto-Response Rules, Workflow Rules, Workflow Field Updates, Escalation Rules, Process Builder, and Entitlement Rules may execute depending on your org configuration.
• Roll-Up Summary Evaluation occurs only when the saved record participates in a Master-Detail relationship with Roll-Up Summary fields.
• Parent record recalculation can trigger additional save operations, causing a new Order of Execution cycle on the parent record.
• The record receives its Salesforce Id before the transaction commits. An unhandled exception later in the transaction can still roll back the entire save.
• Before-Save Flows execute before Before Triggers. Validation Rules evaluate the final field values after all before-save automation has completed.
• After Triggers and After-Save Flows run within the same transaction and share the same governor limit context.
• Queueable Apex, Future Methods, Batch Apex, and Scheduled Apex do not run as part of this transaction. They execute later in separate transactions after a successful commit.
• Agentforce does not add a new execution stage. Agent-initiated record operations follow the same Order of Execution as user and API updates.
• All automation in a transaction shares the same governor limits, including Flows, Apex Triggers, Invocable Apex, and Workflow-triggered re-execution.
• Any unhandled exception before the final commit causes the entire transaction to roll back. Salesforce does not perform partial commits within a transaction.
Governor Limits & Order of Execution
This is the architect-level insight most articles miss entirely.
Every automation tool that runs within a single save transaction shares one governor limit context.
This means:
What this means in practice:
Most governor limit failures occur because teams assume each automation tool runs in its own isolated context.
They do not.
If your Before-Save Flow performs 25 SOQL queries, your Before Trigger performs 25 SOQL queries, and your After-Save Flow performs 25 SOQL queries — you have already consumed 75 of your 100 synchronous SOQL query limit in a single transaction — and no user-initiated query has run yet.
Architect-level rules:
Avoid redundant SOQL queries across automation layers — query once, cache in a static map, reuse
Be especially cautious with Workflow-triggered re-execution — it restarts the automation chain and doubles your limit consumption
Use Limits.getQueries() and Limits.getLimitQueries() in Apex to monitor usage during development
When designing multi-automation transactions, map out total SOQL, DML, CPU time, and heap usage across all tools — not just within each tool individually
apex
// Add this to your Trigger Handler during development
System.debug('SOQL used: ' + Limits.getQueries() + ' of ' + Limits.getLimitQueries());
System.debug('DML used: ' + Limits.getDmlStatements() + ' of ' + Limits.getLimitDmlStatements());
System.debug('CPU time: ' + Limits.getCpuTime() + ' of ' + Limits.getLimitCpuTime());
The hidden cost of legacy automation:
If a Workflow Rule fires a Field Update (Stage 13), Stages 03–08 re-run. Every SOQL query and DML operation in your Triggers fires again. In orgs with both Workflow Rules and complex Triggers, this is one of the most common causes of System.LimitException: Too many SOQL queries: 201 in production.
This is why migrating from Workflow Rules to Flow is not just a modernisation exercise — it is a governor limit protection strategy.
Modern Salesforce 2026 — What Actually Runs
Use these (modern, supported, recommended):
✅ Before-Save Record-Triggered Flows
✅ After-Save Record-Triggered Flows
✅ Apex Triggers with Trigger Frameworks
✅ Validation Rules
✅ Duplicate Rules
Migrate away from: ⚠️ Workflow Rules → migrate to Flow ⚠️ Process Builder → migrate to Flow (no longer being enhanced)
Where Agentforce Fits in the Order of Execution
Agentforce does NOT introduce a new stage into the Order of Execution.
When an Agentforce agent takes an action that creates or updates a Salesforce record — the standard Order of Execution applies in full:
Agent Action (e.g. update a Lead record)
↓
Before-Save Flow
↓
Before Trigger
↓
Validation Rules
↓
Database Save
↓
After Trigger
↓
After-Save Flow
↓
Database Commit ✅
What this means practically:
Validation Rules protect data integrity from Agent-driven updates
Triggers fire whether the save came from a user, an API, or an Agent
Flows run as normal regardless of what initiated the save
Governor limits apply to Agent-initiated transactions exactly as they do to user-initiated ones
This is Salesforce's platform guarantee — the Order of Execution is consistent across all entry points. Build your Agentforce solutions with this in mind.
The Automation Ownership Principle
The Most Important Architect Practice Nobody Teaches
One of the most common causes of production incidents in Salesforce orgs is multiple automation tools modifying the same field.
❌ BAD DESIGN:
Lead Score field:
→ Before-Save Flow updates it to 50
→ Before Trigger updates it to 75
→ After-Save Flow updates it back to 50
→ Nobody knows what the correct value should be
This creates:
Unpredictable field values
Untestable automation chains
Impossible-to-debug behaviour
Failed deployments and production incidents
✅ GOOD DESIGN — Automation Ownership Principle:
Each field must have exactly ONE automation tool that owns it.
Lead Score field:
→ Owned exclusively by the After-Save Flow
→ No Trigger, no other Flow updates this field
→ Documented in your automation inventory
Rules to follow:
Create an automation inventory document for your org
For every automated field update, document which tool owns it
During code review, flag any PR that updates a field already owned by another tool
If two tools legitimately need to update the same field, consolidate them into one
The Automation Ownership Principle is what separates orgs that scale cleanly from orgs that become unmaintainable over time.
Flow vs Trigger — When to Use Which
The 5 Things That Surprise Everyone
Surprise 1 — Validation Rules run AFTER Before-Save Flows AND Before Triggers Your Validation Rule validates the FINAL field values set by all before-save automation — not the original user input.
Surprise 2 — Triggers cannot directly perform HTTP callouts Triggers enqueue async work (Queueable, @future, Platform Events). The callout executes asynchronously in a separate transaction — not immediately after commit.
Surprise 3 — All automation shares one governor limit context Flow SOQL, Trigger SOQL, Invocable Apex, and Workflow re-runs all count toward the same transaction limits. Teams that don't know this hit LimitException in production.
Surprise 4 — Roll-Up Summary updates can cascade Parent record recalculation can trigger additional saves, which run their own Order of Execution and consume additional governor limit resources.
Surprise 5 — Agentforce agent actions run the same Order of Execution When an Agent creates or updates a record, Validation Rules, Triggers, and Flows all fire — just as they would for a manual save.
Interview Trap Questions
Trap #1 — Does the Validation Rule run before or after the Before Trigger?
Most people say: "Before Trigger runs, then Validation Rule."
Full answer:
Before-Save Flow (Stage 02)
→ Before Trigger (Stage 03)
→ System Validation (Stage 04)
→ Validation Rule (Stage 05)
The Validation Rule validates the FINAL value after all before-save automation.
Trap #2 — Can a Before Trigger access the record's ID?
Most people say: "No — ID isn't available in Before Triggers."
Full answer:
Before INSERT — The record's ID is NOT yet available. ID is assigned at Stage 07.
Before UPDATE — The record's ID IS available. The record already exists in the database.
The nuance is the operation type, not just the trigger timing.
Trap #3 — Which is faster — Before-Save Flow or Before Trigger?
Accurate answer: Before-Save Flows are optimised for simple field updates — they operate in-memory without a DML round-trip, reducing transaction overhead for lightweight operations.
For complex multi-object logic, Apex Triggers with proper bulkification often perform better overall.
Match the tool to the requirement. Do not optimise prematurely.
Trap #4 — What happens if a Before-Save Flow and Before Trigger both update the same field?
Architect-safe answer: Avoid this design entirely. Even though Before-Save Flows and Before Triggers have a defined execution sequence, conflicting ownership creates maintenance and debugging problems that compound over time. Assign each field to exactly one automation tool.
Trap #5 — Does Agentforce add a new step to the Order of Execution?
Answer: No. Agentforce does not add a new stage. When an Agent performs a record operation, the standard Order of Execution applies in full — including governor limits.
Trap #6 — Do all automation tools share governor limits in one transaction?
Answer: Yes. Flow SOQL, Trigger SOQL, Invocable Apex, and Workflow-triggered re-execution all count toward the same transaction limits. Designing automation without considering cross-tool limit consumption is one of the most common causes of production LimitException errors.
Hands-On Exercise
Try this in your free Developer Org — developer.salesforce.com/signup
SETUP:
Before-Save Record-Triggered Flow on Contact (Before Insert) → Sets Title = 'Set by Before-Save Flow'
Before Insert Trigger on Contact:
apex
trigger ContactBeforeSave on Contact (before insert) {
for (Contact c : Trigger.new) {
c.Description = 'Set by Before Trigger';
}
}
- Validation Rule on Contact:
Formula: ISBLANK(LeadSource)
Error: "Lead Source is required"
- After Insert Trigger on Contact:
apex
trigger ContactAfterInsert on Contact (after insert) {
System.debug('SOQL used so far: ' + Limits.getQueries());
System.debug('After Trigger: ID = ' + Trigger.new[0].Id);
}
TEST 1 — Insert without LeadSource (expect failure)
apex
insert new Contact(FirstName='Order', LastName='Test');
Observe:
Stage 01: System Validation passes ✅
Stage 02: Before-Save Flow → Title set
Stage 03: Before Trigger → Description set
Stage 05: Validation Rule fires → ISBLANK(LeadSource) = TRUE → DmlException
Transaction rolls back ❌ — After Trigger and After-Save Flow never run
TEST 2 — Insert with LeadSource (expect success)
apex
insert new Contact(
FirstName='Order',
LastName='Test',
LeadSource='Web'
);
Observe:
Stage 02: Before-Save Flow → Title = 'Set by Before-Save Flow'
Stage 03: Before Trigger → Description = 'Set by Before Trigger'
Stage 05: Validation passes ✅
Stage 07: Record saved → ID assigned
Stage 08: After Trigger fires → logs Contact ID and SOQL usage
Stage 18: Committed ✅
Check the saved record — Title and Description both set by different tools, each owning one field. That is the Automation Ownership Principle in action.
Certification Cheat Sheet
Free Resources
🆓 Official Salesforce Execution Order Docs — developer.salesforce.com → search "Order of Execution"
🆓 Trailhead: Apex Triggers module — trailhead.salesforce.com → search "Apex Triggers"
🆓 Trailhead: Flow Builder Basics — trailhead.salesforce.com → search "Flow Builder"
🆓 Trailhead: Agentforce — trailhead.salesforce.com → search "Agentforce"
🆓 Trailhead: Governor Limits — trailhead.salesforce.com → search "Governor Limits"
🆓 Free Agentforce Developer Org — developer.salesforce.com/signup
Final Thought
The Order of Execution is not a topic you learn once and forget.
It is the mental model you apply every time you build automation in Salesforce.
Every trigger you write. Every Flow you build. Every Validation Rule you configure. Every Agentforce agent you deploy.
When something breaks in production, this sequence is where your debugging starts.
And the Automation Ownership Principle — one tool, one field — combined with an understanding of shared governor limits, is what keeps it from breaking in the first place.
Learn all three. Apply all three. Teach all three.
That is how you build Salesforce at scale.
Question for You
Which of these surprised you most?
🔵 All automation shares one governor limit context — not separate per tool 🟡 Agentforce follows the same Order of Execution as a manual save 🔴 Roll-Up Summary updates cascade and can trigger parent saves ⚪ Process Builder is still running in many orgs — not fully gone
Drop your answer in the comments — and share the Automation Ownership Principle with your team if this is something you have experienced firsthand.
Written by Dollesh Rathod · Salesforcebydollesh Part of the Salesforce Pulse Newsletter series
Follow Salesforcebydollesh on Hashnode for more Salesforce, Agentforce & AI career content
#Salesforce #OrderOfExecution #ApexTriggers #FlowBuilder #Agentforce #SalesforceAdmin #SalesforceDeveloper #SalesforceArchitect #GovernorLimits #Trailblazer #SalesforcePulse #SalesforceCertification #CRM
