Order of Execution

Why This Is the Most Important Concept in Salesforce Architecture

There is one question that explains more production incidents, more unexpected behaviour, and more failed UAT scenarios in Salesforce than any other: In what order does Salesforce process this record?

The answer is not "triggers run first, then validation rules, then workflows." The actual answer is a specific, documented sequence of 16+ steps — and deviating from that mental model by even one step leads to bugs that are extremely difficult to diagnose if you don't know the sequence.

Every architect and senior developer on a Salesforce programme needs to know this sequence. Every Delivery Manager who is reviewing technical designs needs to know it well enough to ask the right questions. And every CTO who is approving an architecture approach for a heavily automated object needs to understand the implications of adding automation to an already-complex transaction.

The Complete Order of Execution

When a record is saved (inserted, updated, or deleted), Salesforce processes it through the following sequence. This is the full order, in the correct sequence:

Step 1: Load the record from the database (for updates — existing field values are loaded so triggers can access Trigger.old)

Step 2: Execute all before-save flows — Record-triggered flows configured to run Before the record is saved execute first. They can update field values on the current record without an additional DML statement (it's part of the same save operation).

Step 3: Execute all before triggers — Apex triggers marked before insert or before update run here. Like before-save flows, they can modify field values on the in-memory record without additional DML.

Step 4: System validation — Required fields, unique fields, and foreign key checks are evaluated against the record's current state (including any changes from Steps 2 and 3).

Step 5: Custom validation rules — Validation rules configured by admins execute here. They evaluate the record's current field values, including changes made by before-save flows and before triggers.

Step 6: Duplicate rules — Duplicate management rules execute if configured for the object.

Step 7: Save the record to the database — The record is committed to the database (but the transaction is not yet committed — this is a distinction that matters for rollback scenarios).

Step 8: Execute all after triggers — Apex triggers marked after insert or after update run here. The record now has its ID (for inserts) and updated system fields. After triggers are typically used to create related records or update other objects.

Step 9: Assignment rules — Lead and Case assignment rules execute after the record is saved.

Step 10: Auto-response rules — For Leads and Cases, auto-response emails are sent here.

Step 11: Workflow rules (deprecated, but may exist in your org) — Field updates from workflow rules execute here. Critically, field updates from workflow rules trigger a second evaluation — the before triggers run again for the same record.

Step 12: Processes (deprecated, but may exist) — Process Builder automations execute here.

Step 13: Escalation rules — Case escalation rules execute for Cases.

Step 14: Execute all after-save flows — Record-triggered flows configured to run After the record is saved execute here. Unlike before-save flows, changes made here require DML statements (additional writes to the database).

Step 15: Entitlement rules — For Cases with entitlements, milestone automation executes here.

Step 16: Roll-up summary recalculation — If the record is a detail in a master-detail relationship, any roll-up summary fields on the master record are recalculated here.

Step 17: Criteria-based sharing evaluation — Sharing rules are re-evaluated to determine whether the record's sharing needs to change.

Step 18: Commit the transaction — The entire transaction is committed to the database. If any step throws an unhandled exception, the entire transaction rolls back.

Before Save vs After Save: A Critical Distinction

The most important design decision in Salesforce automation is whether your logic belongs in the before-save context or the after-save context. The rules are clear — but frequently violated.

Before-Save (Steps 2 and 3)

Use before-save automation when you need to:

• Set or modify field values on the current record being saved
• Validate field values and prevent the save if conditions aren't met
• Derive field values from related data that's already loaded

Before-save changes to the current record are "free" — they don't consume a DML statement because they're part of the record's in-memory state before it's written to the database. This is a significant performance advantage. A before-trigger that sets 10 field values uses zero DML statements for those updates.

After-Save (Steps 8 and 14)

Use after-save automation when you need to:

• Create related records (child records, task records, notifications)
• Update other records (not the record being saved)
• Make API callouts to external systems (callouts are not allowed in before triggers)
• Query data that was affected by the save (for inserts, the record's ID is not available until after save)

After-save changes require DML statements — every update to another record is a separate database write, consuming from your 150-DML budget.

Automation Interactions: Where Things Go Wrong

The order of execution matters most when multiple types of automation are active on the same object. These interaction patterns are the source of most complex Salesforce debugging scenarios.

Flow Before + Trigger Before

When both a record-triggered Flow (before save) and a before Trigger are active on the same object, the Flow runs first (Step 2), then the Trigger (Step 3). This means the trigger can see the changes the flow made to the record. If both are updating the same field, the trigger's update overwrites the flow's update. If this is not the intended behaviour, you have an architecture problem.

Validation Rule + Before Trigger

Validation rules (Step 5) evaluate the record after before triggers have run. This means a before trigger can set a field value that satisfies a validation rule — or that breaks one. A change in trigger logic that modifies a field value may inadvertently bypass or trigger validation rules. Testing needs to cover the full automation stack, not the trigger in isolation.

After-Save Flow + After Trigger

After triggers (Step 8) run before after-save Flows (Step 14). If an after trigger creates a related record, and an after-save flow needs to operate on that related record, the flow can see it. If an after-save flow creates a related record, and an after trigger is supposed to work with that record, the trigger cannot see it — it ran first.

// After Trigger runs at Step 8 — can see data committed at Step 7
// After-save Flow runs at Step 14 — can see results of after trigger work

// Common Bug Pattern:
// After trigger at Step 8 queries for related records
// After-save Flow at Step 14 creates a related record
// After trigger CANNOT see records created by the after-save flow
// — they didn't exist yet when the trigger ran

// Solution: If you need the trigger to see records created by a flow,
// put the flow logic in a Flow that runs BEFORE the trigger
// (i.e., move it to a before-save flow at Step 2)

How to Debug Using the Order of Execution

When you encounter unexpected behaviour on a heavily automated Salesforce object, the order of execution is your debugging map. Walk through each step systematically:

1. Identify all active automation on the object. Pull a list of: active triggers, active before-save flows, active after-save flows, active validation rules, active workflow rules (legacy), active process builder automations (legacy). Any org that doesn't have this documented is flying blind.

2. Trace the field value through the execution sequence. For the field that's behaving unexpectedly, trace what each piece of automation does to it. Step 2 flow sets it to X. Step 3 trigger sets it to Y (overwrites X). Step 5 validation checks it against Z. Step 11 workflow updates it to W (triggers Steps 2-5 again).

3. Look for the restart pattern. If you have legacy workflow rules with field updates (Step 11), remember that Steps 1-7 execute again for that record. Every before trigger and before flow runs twice. Check whether your automation is idempotent — does running it twice produce the same result as running it once?

4. Check the shared limit consumption. If the unexpected behaviour is a LimitException rather than incorrect field values, the order of execution tells you which automation is consuming limits first and whether a downstream automation is failing because the budget is already exhausted.

Practical Implications for Architecture Decisions

Understanding the order of execution changes how you approach automation design decisions.

When adding automation to a heavily automated object: Before adding any new trigger or flow, produce the current automation inventory. Map the execution sequence for the automation that already exists. Then determine where your new automation fits in the sequence and what it will see — and what will see it.

When choosing between a Trigger and a Flow: For simple field-update logic, a before-save Flow (Step 2) is appropriate and requires no DML. For complex conditional logic that references related records not available in the before-save context, a before Trigger (Step 3) may be necessary. For cross-object updates, an after-save Flow (Step 14) or after Trigger (Step 8) is required — and the choice between them depends on whether other automations downstream of the save need to see the results.

When decommissioning legacy automation: Before removing a Workflow Rule or Process Builder automation, map the order of execution before and after removal. Sometimes legacy automation is compensating for a bug in a trigger — removing it exposes the bug rather than simplifying the architecture.