As Salesforce Developers and Salesforce Administrators, we need to understand how the system will process and validate the data that we are inserting or manipulating. As any system does, the rules follow a general pattern that’s known as the Salesforce Order of Execution. As a Salesforce Organization gets more and more customized, you will most likely have validation rules, workflow rules, assignment rules, and probably lots of apex triggers.

As a developer or admin, we need to understand exactly how the system works to produce reliable and consistent code. if you are new to Salesforce or looking to switch jobs, a lot of companies will ask about the execution order of Salesforce in job interviews.

If you are not already familiar with Before and After Triggers, I strongly recommend that you review my blog article What’s the Difference Between Before and After Triggers before you start reading about the execution order.

The order is as follows:

1. Any page validation that has been setup for the particular page layout / custom visualforce page.
2. The original record, if applicable, is loaded from the database.
3. The new record values are applied to the old record
4. System Validation Rules which are the rules that Salesforce has setup and are most likely related to the field being required and in the correct format.
5. All of the Before Triggers are executed.
6. Pretty much all of the System Validation Rules are run again to confirm that there’s no non-null values, and that formats haven’t changed. Validation related to page layouts and any custom visualforce pages are the only validation rules that don’t execute again.
7. Custom Defined Validation Rules are now executed again.
8. Duplicate Rules are run. If there’s any duplicates identified then the process stops immediately.
9. The record is saved to the database, but isn’t committed yet. This means that formula fields can now be used.
10. After Triggers are executed.
11. Executes Assignment Rules
12. Executes auto-response rules. Auto-Response rules are emails on cases or leads that let customers know that their request as been received and that somebody will be in touch.
13. Executes Workflow Rules.
14. If any of the workflow rules did updates, the records are updated again which then causes the before and after UPDATE triggers to execute along with any system validation.
15. Processes now execute.
16. Escalation Rules execute.
17. If it’s a Case, Entitlement Rules now execute.
18. If the record that’s being inserted/update has any roll-up summary fields or will be involved with a roll-up summary then the platform will do some processing related to how roll-up summaries work.
19. All of the DML operations are committed to the database.
20. Any applicable emails or other post-commit logic is executed.

While nobody is really expecting you to have the whole process memorized, I think it’s fair to say that when you architecting solutions or debugging code it’s fair to say that you should have a really good working knowledge of how the platform does data operations.

Things to Keep In Mind About The Order of Execution

The order of execution is usually slightly modified at least once a year. In the six years or so that I’ve worked on Salesforce, I’ve been caught quite a few changes by changes to it that I didn’t expect. For example, when processes were released I didn’t know that they would execute after all of the workflow rules and won’t necessarily refire all of the workflows.

If you are using triggers to do certain things and have multiple triggers instead of having one Trigger to Rule them All that the order in which each trigger is executed isn’t necessarily guaranteed which can result in some really strange and unexpected things happening. In general, it’s a really good practice to have as few triggers as possible because they will be executed multiple times.

Trigger.old isn’t normally the values that were previously stored in the database. Usually the values will actually be the values that were updated in the previous step, unless it’s a workflow, which will be the values before the workflow executed.