Triggers and Order of Execution
March 6th, 2009
This topic came up again today in reference to a trigger to modify lead assignments. It’s always important to keep the order of these events in mind when developing as it can cause unintended consequences and a debugging nightmare.
When a record is saved with an insert, update, or upsert statement, the following events occur in order:
1. The original record is loaded from the database (or initialized for an insert statement)
2. The new record field values are loaded from the request and overwrite the old values
3. System validation occurs, such as verifying that all required fields have a non-null value, and running any user-defined validation rules
4. All before triggers execute
5. The record is saved to the database, but not yet committed
6. All after triggers execute
7. Assignment rules execute
8. Auto-response rules execute
9. Workflow rules execute
10. If there are workflow field updates, the record is updated again
11. If the record was updated with workflow field updates, before and after triggers fire one more time (and only one more time)
12. Escalation rules execute
13. All DML operations are committed to the database
14. Post-commit logic executes, such as sending email
Categories: Apex, Salesforce
After triggers can cause recursion (by doing dml on the object being triggered), which makes this ordering even more complicated. I recommend staying away from that kind of recursion if possible, just for your own sanity’s sake.
I’ve run into this too, especially with triggers and integrations. This Salesforce doc has a little more info, btw:
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_order_of_execution.htm