If you’ve spent any time building automation in Salesforce, you’ve probably heard this Golden Rule: "Always update fields on the triggering record using a Before-Save Flow !" It sounds simple enough, but why is this rule so heavily emphasized? What actually happens under the hood when you update a record inside an After-Save Flow instead? Does Salesforce rewind everything back to Step 1? Let’s lift the hood on the Salesforce Order of Execution, break down what happens during a record update in plain English, and look at how to build faster, cleaner automation. The Basics: The Salesforce "Assembly Line" Whenever a user clicks Save on a record, Salesforce doesn't just write the data to a database and call it a day. It passes the record through a strict, multi-step assembly line called the Order of Execution . Here is a simplified look at what happens in order: Loads the record and applies your new field values. System Checks: Verifies required fields and bas...
💬 In plain
words: When you press Save,
Salesforce runs a fixed assembly line: checks → before automation → save →
after automation → related updates → commit. Half of all tricky bugs are just
two steps of this line writing the same field. Learn the line once and those
bugs become obvious.
📌 Example: A validation rule demands Discount ≤ 20%. A
workflow field update later sets Discount = 25% — and saves fine, because
workflow runs AFTER validation. Users can't break the rule; your own automation
just did. That's why order matters.
🎬 Real-Life
Example: The Field That Kept Changing Itself Back A Flow sets Priority__c to High for same-day
parcels. Yet saved records keep showing Normal. The admin swears the Flow runs.
The developer swears the trigger works. Both are right.
The Old/Bad Way: The before-save Flow sets High. Then a before
trigger — written two years earlier — recalculates Priority and overwrites it.
Nobody knew both existed. The "fix" was a third automation, after
save, updating the record again: one more save, one more full pass through
every rule.
Why this is bad: When two steps own one field, the later step
always wins — silently. Fixes stacked in the wrong step run the whole order of
execution twice and invite recursion.
The New/Good Way: 1. Learn the order cold: before-save flows →
before triggers → validation rules → save → after triggers → after-save flows →
roll-ups → commit. 2. Give every field ONE owner in ONE step. 3. Same-record
field math belongs in a before-save step, where it needs no extra update at
all.
The payoff: One field, one owner, one step. The order of
execution is not trivia — it is the map of who wins.
Concept
Order of
Execution is the classic 'do you understand the platform' question.
1. Here is one record save, simplified, in
order.
2. The record is loaded. System validation runs.
3. Record-triggered BEFORE-save flows run.
BEFORE triggers run.
4. System and custom validation rules run.
5. Duplicate rules run. The record is saved, but
not committed.
6. AFTER triggers run. Assignment rules run.
7. Auto-response rules run. Workflow rules run —
retired tech, unsupported since Dec 31, 2025, though old rules still execute.
8. A workflow field update re-fires the before
and after UPDATE triggers, once.
9. Escalation rules run. AFTER-save
record-triggered flows run.
10. Entitlement processing runs. Roll-up summary
fields recalculate on the parents.
11. Criteria-based sharing is evaluated. Then
COMMIT.
12. After the commit comes the post-commit work:
emails, and any async Apex enqueued during the transaction.
13. Two things sit outside that list.
14. Formulas are computed when you read them —
they are not stored, and they are not part of the save.
15. Roll-ups are stored, and they recalculate inside the parent's save cycle.
SAVE ORDER (single record) — key
stops:
1. Load record + apply new values
2. System validation (required, field types)
3. Before-save record-triggered FLOWS ← cheapest place
4. BEFORE triggers
5. Custom validation rules + duplicate rules
6. Record SAVED (not committed)
7. AFTER triggers
8. Assignment / auto-response / WORKFLOW
(field update re-fires triggers)
9. After-save record-triggered FLOWS ← extra save cycle
10. Roll-up summary on parent (may
re-run parent's rules)
11. Criteria-based sharing eval
12. COMMIT → emails, async Apex, platform events
(after-commit)
🧠 Order of Execution — "Very Big Rabbits Dig Straight After Winter, Eating Roots Post-Commit": system Validation → Before-save flow → Before triggers → validation Rules → Duplicate rules → Save → After triggers → Workflow → (flows) → Escalation → Roll-ups → Post-Commit (email, async).
🧭 360 Card —
Order of Execution
Rule: learn the save order. Half of the strange bugs
are two steps in the wrong sequence.
Gain: a before-save flow is the cheapest place to set
a field on the record being saved. No extra save cycle, no DML.
Price: the order is fixed. You cannot reorder it. Your
only lever is choosing which stage to use.
Limits: a workflow field update re-runs before and
after triggers once, but does not re-run validation or duplicate rules. Roll-up
summaries can re-fire the parent’s own rules. Emails, async Apex and platform
events fire only after commit.
Mirror — after-save
flow: can reach related records, at the cost
of a second save cycle on the same record.
Later: every automation topic in Modules 5 and 6 hangs
off this timeline.
At volume: each extra save cycle multiplies by row count.
In a 10,000-row load, one needless after-save flow is 10,000 extra saves.
⚠ INTERVIEW TRAP: When two automations write the same field, the
later one wins — silently, with no error. That is why one layer must own each
field.
Core Q&A
Q: A workflow field update
sets a field. And the update triggers fire again. But a validation rule you
expected to block it doesn't. Explain.
🎯
Say this first: Workflow field updates re-fire triggers
but skip validation rules. Automation can write what a user could not. That is
why same-record logic belongs before save.
A: A
workflow field update re-runs the before and after update triggers, once. It
does NOT re-run validation rules, duplicate rules, or most of the
earlier pipeline.
• So a workflow can write a value that a validation
rule would have rejected from a user.
• That is a real integrity hole, and it is one
reason to migrate workflow field updates to before-save flows or before
triggers. Those run inside the validated part of the pipeline.
• Worth adding: this re-fire behavior is
exactly why trigger handlers need recursion guards in the first place.
Follow-ups (scenario-based)
Q1: Where in the order do
record-triggered flows run relative to Apex triggers. And why does it matter
for who 'wins' a field write?
A1: Before-save
flows run BEFORE before-triggers.
• After-save flows run AFTER after-triggers,
and after workflow.
• So when a before-save flow and a
before trigger both write the same field on the same record, the trigger wins.
It runs later in the before phase.
• The after phase is different. An after-save
flow's update starts a NEW save cycle: extra DML, and triggers fire
again.
• Before-save writes are free by comparison.
That is why same-record updates belong in the before phase, whether you use
flow or trigger. And it is why 'my flow overwrote my trigger' is really a
question about ordering.
Q2: During a data load, saves
are slow and you suspect the save pipeline. How do you diagnose which stage
costs the time?
A2: Turn
the order of execution into a checklist.
1. Debug logs with profiling show you where the
trigger and flow time goes. Then look for the usual offenders.
2. After-save flows and workflow field updates
causing a second save cycle.
3. Roll-up summary recalculation on wide
parents, where every child save touches the parent.
4. Criteria-based sharing recalculation.
Cross-object formulas forcing a parent read.
5. The fixes map back onto the stages.
6. Move same-record after-save automation
into before-save.
7. Set bypass switches for migration users — see
2.3.
8. Defer sharing calculation. Load parents
before children, so you are not retrying locks.
9. Diagnosing by pipeline stage, instead of
guessing, is the architect signal.
📝 2-Minute
Self-Check
Q1. An Invoice Line must never exist without its
Invoice. Which relationship?
A1. Master-Detail. The child cannot live alone, and
you get cascade delete and roll-ups free (2.1).
Q2. Marketing says a field they capture on the Lead
never arrives on the Contact. Why?
A2. Only standard fields map on conversion. The
custom field has no mapping, so it is dropped silently (15.2).
Q3. You must store config that deploys with the app
and is read inside a loop. What do you use?
A3. Custom Metadata. Its reads cost no SOQL and the
records travel in the package (2.3).
Q: Workflow Rules are retired. Does the
order of execution answer change?
A: The
ladder is the same. Only the names change.
• Workflow Rules and Process Builder are
retired, so a current answer describes record-triggered flows, not workflow.
• Keep the old step in your head for two
reasons.
• Legacy orgs still run migrated automation.
And interviewers still ask why a validation rule failed to block a field
update.