Order of Execution in Salesforce, Explained Simply (2026)

A single click on Save can set off more than twenty separate steps before Salesforce tells you the record is done.

If you work on Salesforce, or want to, you'll be asked about this in interviews. More importantly, you'll be blamed for it when a field changes on its own and nobody knows why.

This page is a plain-English reference for the order of execution in Salesforce. It follows the official sequence from Salesforce's own documentation, with questions grouped by level and a short note on what I look for when I hire.

Key takeaways

• The order of execution in Salesforce is the fixed sequence of steps (validation, before-save automation, triggers, the database save, after-save automation, commit) that runs every time a record is inserted, updated or upserted.
• You don't need to memorise every step; you need to know the landmarks and what belongs where: before-save for field changes on the same record, after-save for work that needs the record Id or touches other records.
• Most "mystery" bugs come from automations on the same object that nobody mapped, plus workflow field updates that re-fire triggers.
• Every automation in a transaction shares one set of governor limits, so a design that looks fine for one record can fail on 200.

Why the order of execution in Salesforce matters more than the list itself

My argument is simple: treat the order of execution as a debugging tool and a design tool, not a list to recite.

Interviews reward the list. Production rewards the reasoning. When two things on one object disagree, the person who can say "that flow runs before the trigger, so the trigger overwrites it" fixes the problem in ten minutes. The person who memorised 21 steps and can't apply them is still guessing at hour three.

If you don't understand what happens under the surface, you build technical debt, and you start hitting limit errors.

There's a reason this is getting more important, not less. Every automation you add to an object joins the same queue. Flows, triggers, validation rules, duplicate rules, roll-ups. The longer an org lives, the more of them stack up on Account, Opportunity and Case. I've worked on Salesforce since 2008, and in my judgement the stack, not any single tool, is what causes most automation pain.

The official order of execution in Salesforce, step by step

Here is the sequence from the Apex Developer Guide, in the order Salesforce documents it.

Salesforce updates this page between releases and the numbering can shift, so check the live page before an exam or a code review. For a visual version, the Data Model Gallery has an Order of Execution flowchart.

#	Step	In plain English
1	Load the original record from the database, or initialise it for an upsert	Salesforce gets the "old" version to compare against
2	Load new field values from the request and overwrite the old values; run system validation (for UI edits: layout rules, required fields, formats, max length; for Apex/API: foreign keys and restricted picklist values)	Your changes land on the record; basic checks run
3	Run record-triggered flows set to run before save	Fast field updates on the same record, no DML needed
4	Run all before triggers	Your Apex gets the first look at the data
5	Run most system validation again, then user-defined validation rules	Your custom rules judge the record, after before-save automation has had its say
6	Run duplicate rules (a block action stops the save and skips later steps such as after triggers)	Duplicates can end the transaction here
7	Save the record to the database, but don't commit yet	The record exists inside the transaction, with an Id
8	Run all after triggers	Apex that needs the Id or touches related records
9	Run assignment rules	Lead and case owners get set
10	Run auto-response rules	Automatic acknowledgement emails
11	Run workflow rules; apply any workflow field updates to the record	The legacy tool; field updates change the record again
12	If workflow field updates changed the record, fire before update and after update triggers once more, plus standard validations	The famous "triggers fire twice" step; custom validation rules, flows, duplicate rules, Process Builder processes and escalation rules don't re-run
13	Run escalation rules	Case escalation
14	Run Process Builder processes and flows they launch (and flows launched by workflow actions); order isn't guaranteed	Legacy automation; any DML here sends affected records through the save procedure
15	Run record-triggered flows set to run after save	Flows that create or update other records
16	Run entitlement rules	Support entitlements
17	Roll-up summary and cross-object workflow calculations; the parent record goes through the save procedure	Parent totals update
18	The same again for a grandparent record, if the parent changed	Roll-ups can climb more than one level
19	Run criteria-based sharing evaluation	Sharing recalculates
20	Commit all DML operations to the database	The point of no return
21	Run post-commit logic: send emails, run enqueued async Apex (queueable jobs, future methods) and asynchronous paths in record-triggered flows	Work that must only happen if everything succeeded

You don't need all 21 in your head. Remember seven landmarks: before-save flow, before trigger, validation, save, after trigger, after-save flow, commit.

My take: Learn the seven landmarks first, then hang the other steps on them. When a candidate can place any automation at the right landmark and explain why, I stop worrying about whether they can recite step 16.

Order of execution in Salesforce interview questions for freshers

At this level, interviewers want to see that you understand the big picture and the vocabulary, not the edge cases. These are the questions I'd use to test understanding. They aren't copied from any exam.

1. What is the order of execution in Salesforce?

It's the documented sequence of events Salesforce runs when a record is inserted, updated or upserted. It covers validation, flows, triggers, rules, the database save, roll-ups and commit. Everything happens inside one transaction, and if anything fails, the whole thing rolls back.

2. What's the difference between a before trigger and an after trigger?

A before trigger runs before the record is saved to the database (step 4). You can change field values on Trigger.new directly, with no DML. The record has no Id yet on insert.

An after trigger runs after the save but before commit (step 8). The record has an Id, but Trigger.new is read-only.

trigger AccountTrigger on Account (before insert, before update, after insert) {
    if (Trigger.isBefore) {
        for (Account a : Trigger.new) {
            if (a.Rating == null) {
                a.Rating = 'Warm'; // no DML needed in a before trigger
            }
        }
    }

    if (Trigger.isAfter && Trigger.isInsert) {
        List<Task> tasks = new List<Task>();
        for (Account a : Trigger.new) {
            tasks.add(new Task(WhatId = a.Id, Subject = 'Welcome call')); // Id exists now
        }
        insert tasks; // one DML statement for all records
    }
}

3. Do validation rules run before or after before triggers?

After. Validation rules run at step 5, once before-save flows and before triggers have finished. So a before trigger can fix or populate a value that a validation rule then checks.

4. Which runs first: a flow or a trigger?

It depends on the type of flow. A record-triggered flow set to run before save runs first (step 3), then before triggers (step 4). After triggers (step 8) run before record-triggered flows set to run after save (step 15).

5. When is data actually committed to the database?

At step 20, after all the automation has finished. Before that, the record is saved inside the transaction (step 7) but not committed, which is why an error anywhere rolls everything back.

6. If I have two triggers on the same object, which runs first?

You can't know. Salesforce documents that the order of multiple triggers on the same object isn't guaranteed. That's the reason most teams write one trigger per object and route logic through a handler class.

Order of execution scenario questions for 2-5 years' experience

At this level, interviewers give you a symptom and want you to find the cause. The answer is almost always "it's where it sits in the order."

7. Why did my trigger fire twice on a single save?

Probably a workflow field update. If a workflow rule updates a field (step 11), Salesforce fires before update and after update triggers one more time, and only one more time (step 12). Your trigger saw the record before and after the workflow change.

If you see this, remember that in the re-fired trigger Trigger.old still holds the values from before the user's edit, so comparing old and new shows the change again. Guard with a set of processed Ids, or check the field the workflow updates.

8. How do you stop a trigger recursing?

Use a static variable, but be careful how. A trigger fires in chunks of up to 200 records, so a simple static Boolean will skip every chunk after the first on a large data load.

A set of processed Ids is safer:

public class TriggerGuard {
    private static Set<Id> processed = new Set<Id>();

    public static Boolean shouldRun(Id recordId) {
        if (processed.contains(recordId)) return false;
        processed.add(recordId);
        return true;
    }
}

This tracks each record rather than the whole transaction. Use it in after triggers or update contexts: in a before-insert trigger records have no Id yet. In my judgement, a guard is a patch. The real fix is usually to remove the second automation that causes the loop.

9. A duplicate rule blocked a record. Did my after trigger run?

No. If a duplicate rule identifies a duplicate and uses the block action, the record isn't saved and later steps, such as after triggers and workflow rules, don't run (step 6).

10. What happens to the parent when a child is saved?

If the parent has a roll-up summary field, Salesforce recalculates it and the parent record goes through the save procedure (step 17). That means the parent's own triggers, validations and flows can fire because a child changed. It catches people out when a harmless child update trips a validation rule on the parent.

11. Where should I put logic that needs the record Id?

In an after trigger or an after-save flow. On insert, the Id doesn't exist until the record is saved to the database (step 7). Before-save logic can't use it.

12. Do all these automations share governor limits?

Yes. Everything in the transaction, including flows, triggers and their DML, counts against one set of limits. The Apex governor limits apply to the whole transaction, not to each tool separately. Salesforce has a worked example of flows hitting APEX_CPU_TIME_LIMIT_EXCEEDED in its help article on bulkified record processing.

My take: The limits question is where good developers separate from average ones. A flow, a trigger and a roll-up that each look cheap can add up to a CPU timeout when someone loads 200 records. Test with bulk data before you ship, not after.

Order of execution in Salesforce for senior developers: design and debugging

At senior level, the question changes from "what happens?" to "how do you stop it getting out of hand?"

13. How do you control the order of several record-triggered flows on one object?

Don't rely on the default. Salesforce lets you set an explicit trigger order for record-triggered flows on an object (Flow Trigger Explorer in Setup shows what's there). If you leave flows unordered, don't assume any sequence.

Better still, consolidate. In my judgement, fewer flows per object and context is a stronger fix than a perfectly ordered pile of them.

14. What do you do about Workflow Rules and Process Builder?

Migrate them to Flow. Support for both ended on 31 December 2025, and while existing automations still run, steps 11 to 14 are where the least predictable ordering sits (the documentation itself says Process Builder and its flows have no guaranteed order). Plan the migration object by object, starting with the ones that fire triggers twice.

15. How do you design automation on a busy object?

Decide ownership per object. Here's the rule I'd defend:

• Before-save flow: simple field defaults and calculations on the same record.
• Before trigger: complex field logic that needs Apex.
• After trigger or after-save flow: anything that needs the Id or creates and updates other records.
• Queueable or future: callouts and work that can wait until after commit.

Pick one tool per job per object, write it down, and keep one owner for each. Apex and Flow both being "allowed" on the same logic is where the stack starts fighting.

16. A field value keeps changing and nobody knows why. How do you debug it?

Start with field history to see when and who. Then use a debug log with Workflow, Apex Code and Database categories at a useful level, and read it in sequence against the table above. The log shows each automation firing in order, so the one that overwrites your value is usually visible within a few minutes.

Then list every flow, trigger and rule on the object, and look for two that write to the same field.

17. What runs after commit, and why does it matter?

Post-commit logic (step 21) includes emails and enqueued asynchronous Apex such as queueable jobs and future methods. Put work there when it must only happen if the whole transaction succeeds. That's why you don't send a "your order is confirmed" message from an after trigger that might still roll back.

My take: There's a new reason to care. When an Agentforce action updates a record through a flow or Apex, that's DML like any other, so it runs the same save sequence. An AI agent doesn't get a shortcut around your validation rules and triggers. I'd say it's one of the safest things about it. It also means an agent that writes to a messy object inherits the mess. That's why mapping this order belongs in the "Architect" stage of my AI-Native Enterprise Framework, which is my own proposal and still evolving.

What a hiring founder looks for in order of execution answers

I look for people who can reason about a record save, not people who can recite one.

At Techila, our interview and assessment questions once ended up on the internet, and candidates walked in knowing the answers. We built a pool of hundreds of thousands of questions and now generate each test in real time, adaptive to how the candidate is doing. That became Talent IQ (talentiq.app).

The lesson applies to you too. Someone can memorise 30 leaked questions. Nobody can memorise hundreds of thousands. So don't go looking for dumps. They age fast, and they teach you to recognise answers instead of understanding the platform.

What I care about instead is whether you can take a symptom ("this field resets to zero") and walk the order out loud: "a before-save flow sets it, the before trigger overwrites it, validation passes, so the bug is in step 4."

Here's what that looks like in practice. When we hire senior Salesforce developers to work with our US customers, four things matter to us: strong hands-on technical skills, excellent communication, experience working with US customers, and being comfortable working US Eastern Time hours. Walking the order of execution out loud tests the first two at once. You can't fake having debugged a record save, and you have to explain it so the customer's team can follow.

If you're building your profile, teaching helps. Credibility in the Salesforce community comes from helping people, and explaining this topic to a colleague will teach you more than rereading it.

How do I practise the order of execution in Salesforce?

Try this week:

• Open the official order of execution and mark the seven landmarks on a sheet of paper from memory.
• In a developer org, create a before-save flow, a before trigger and a validation rule on Account, then read the debug log to see them fire in order.
• Add a workflow field update to the same object and watch the triggers fire a second time.
• List every automation on your most-edited object and note which ones write to the same fields.

If you'd like to go deeper on how I approach this in real org work, one of my sessions is the place, and I share small builds in my experiments.

Frequently asked questions

What is the order of execution in Salesforce?

It's the fixed sequence Salesforce follows when a record is inserted, updated or upserted: load the record, validate, run before-save flows and before triggers, run validation rules and duplicate rules, save, run after triggers and other automation, calculate roll-ups, then commit. The official version is in the Apex Developer Guide.

Does a flow run before a trigger in Salesforce?

A record-triggered flow set to run before save runs before before triggers. After triggers run before record-triggered flows set to run after save. So "flow first" or "trigger first" depends on which kind of flow it is.

Do validation rules run before or after triggers?

Validation rules run between the before triggers and the database save. They see whatever the before-save flows and before triggers did to the record, and they run before after triggers.

Is the order of execution still relevant with Flow and Agentforce?

Yes. Flows and Agentforce actions that change records go through the same save procedure as any other DML, so the same sequence, limits and conflicts apply. Understanding it is how you stop an agent or a flow from silently undoing another automation's work.