Why the Trigger Order of Execution Matters
Understanding Salesforce trigger order of execution is essential for building predictable, maintainable Apex. The platform processes many declarative and programmatic operations for a single record change — validation rules, triggers, workflows, processes, and more. Getting the sequence right helps avoid data corruption, recursion, unexpected behavior, and governor limit issues.
Salesforce Trigger Order of Execution — Step-by-step
Below is a concise, SEO-friendly, and developer-focused sequence you can rely on when designing triggers and automation. Keywords: Salesforce trigger order of execution, Apex triggers, workflow field update, before triggers, after triggers.
1. System initializations and original record loaded (for updates)
– Salesforce loads the original record (if updating) and the new values submitted for the change.
2. System validations (required fields, field formats)
– Basic system checks run. These include field-level validations enforced by the platform (not custom validation rules).
3. Before-save flows (fast field updates) and Before triggers
– Any before-save Flow (Record-Triggered Flow configured to run before save) executes first — these are optimized for fast updates.
– Then Apex before triggers run, allowing you to update record values before they’re saved to the database.
4. Custom validation rules
– Salesforce runs validation rules declared in the object configuration. If any validation fails, the transaction is rolled back.
5. After triggers
– Apex after triggers execute. Use these when your logic depends on record Ids or related data that require the record to be committed to the record context.
6. Assignment rules, auto-response rules
– Lead and Case assignment rules, plus any auto-response rules, are evaluated and executed.
7. Workflow rules (and workflow field updates)
– Workflow rules execute. If a workflow rule performs a field update, Salesforce will re-run triggers and validation rules for the affected record:
– Workflow field update leads to a second round: Before triggers & After triggers → Validation → (and so on).
8. Processes and Flows (after-save Record-Triggered Flows / Process Builder)
– After workflow rules, Process Builder processes and after-save Flows execute. These can also perform updates which may cause additional trigger executions (similar to workflow field updates).
9. Escalation rules, entitlement rules, and other automation
– Other platform automations like escalation rules run.
10. Roll-up summary recalculation and parent updates
– If roll-up summary fields are affected, parent records are updated. That update can cause another execution cycle for the parent (before/after triggers on parent object).
11. Criteria-based sharing
– Sharing rules based on criteria are evaluated and applied.
12. Commit
– Database commit occurs. All DML changes are saved.
13. Post-commit actions (email, outbound messages, asynchronous Apex)
– Actions that run after commit include sending email notifications, outbound messages, and launching asynchronous Apex (future/Queueable jobs may be queued). These run outside the main transaction.
– Platform events, asynchronous processes, and callouts invoked from post-commit processes execute separately.
Important Notes and Best Practices
– Avoid complex logic in multiple places. Prefer a single handler framework per object to centralize trigger behavior.
– Beware of workflows/processes that cause additional trigger re-entry (recursion). Use static variables or a trigger framework to prevent infinite loops.
Example: Preventing Trigger Recursion (pattern)
public class TriggerHelper {
public static Boolean hasRun = false;
}
trigger AccountTrigger on Account (before insert, before update) {
if(TriggerHelper.hasRun) return;
TriggerHelper.hasRun = true;
// Your logic here
}
– Set and check a static Boolean (or a Map keyed by record Id) to prevent the same logic from running multiple times during a transaction caused by workflow/flow updates.
Quick Checklist when Troubleshooting Order Issues
- Identify which automation (Validation, Flow, Workflow, Process Builder, Trigger) is causing the unexpected update.
- Use debug logs and transaction IDs to trace the full execution path.
- Minimize cross-dependencies between declarative automation and Apex.
- Prefer before-save Flows for simple field updates (they’re much faster than triggers).
Summary
Salesforce executes many automation steps in a predictable order. Knowing the order—system validations, before-save flows, before triggers, validation rules, after triggers, workflows, processes, roll-ups, and finally commit/post-commit actions—helps you design robust Apex and declarative automation. Keep logic centralized, avoid recursion, and use debug logs to validate behavior.