Salesforce Basics: Formulas, Validation Rules & Order of Execution in Salesforce

💬 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 (legacy technology, 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 parent records.
11. Criteria-based sharing is evaluated. Then COMMIT.
12. After the commit comes post-commit work: emails, platform events, and any async Apex enqueued during the transaction.
13. Two things sit outside that list: Formulas are computed dynamically when read (not stored, not part of the save pipeline). Roll-ups are stored and 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 all 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 trigger and flow architecture 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 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 interface save.
• That is a real data integrity risk, and it is a core reason to migrate legacy workflow field updates to before-save flows or before triggers, which execute inside the validated pipeline stage.
• Architect Note: This re-fire behavior is precisely why Apex trigger handlers require recursion guards.

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 workflows.

• When a before-save flow and a before trigger both write to the same field on the same record, the trigger wins because it executes later in the before phase.
• An after-save flow's update triggers a NEW save cycle: extra DML statements execute, and triggers fire again.
• Before-save writes are essentially free in terms of governor limits. Same-record updates belong in the before phase whether using Flow or Apex.

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 diagnostic checklist:

1. Enable Debug Logs with profiling to isolate trigger execution vs. Flow runtime.
2. Identify after-save flows and workflow field updates triggering secondary save cycles.
3. Check Roll-up Summary field recalculations on wide parent records where child saves lock the parent.
4. Audit criteria-based sharing recalculation and cross-object formulas forcing parent reads.
5. Apply target fixes: Move same-record after-save automation into before-save, set bypass switches for data migration users, defer sharing calculations, and load parent records prior to child records to avoid row locking.

📝 2-Minute Self-Check

Q1. An Invoice Line must never exist without its Invoice. Which relationship?

A1. Master-Detail. The child cannot exist independently, giving you cascade delete and roll-ups automatically.

Q2. Marketing says a field they capture on the Lead never arrives on the Contact. Why?

A2. Only standard fields map automatically on conversion. Custom fields drop silently if custom field mapping is not configured.

Q3. You must store config that deploys with the app and is read inside a loop. What do you use?

A3. Custom Metadata Types. Reads consume no SOQL governor limits and records deploy cleanly in packages.

Q: Workflow Rules are retired. Does the order of execution answer change?

A: The sequence structure remains identical; only the tooling evolves. Record-triggered flows occupy the before and after positions previously associated with legacy tools. Legacy orgs still run migrated automation, and understanding the workflow re-fire step remains critical for explaining why legacy field updates bypassed validation rules compared to modern After-Save Flow updates that initiate a complete secondary save cycle.