Understanding the “Order of Execution” is extremely important for many, many, many reasons. I have helped many developers (including some very experienced ones) where the solution was on this Apex documentation page:
So please memorize it! You must be able to recite it even when you are drunk… assuming you go to the same kind of parties I attend. But that will have to be part of another blog ;-)
I was flying once from Toronto to San Francisco, thinking how I was going to help my students memorize this document when I came with a great idea... and I built this Powerpoint deck:
AR WE RUShD.pptx
I broke the information in two parts: The obvious and the difficult part.
The obvious part:
1) If you are updating a record, the original record (with the old values) gets loaded from the database, but if you are inserting a record, a blank record with default values is created. These values can be obtained from a trigger with trigger.old or declaratively using the ISCHANGED() or PRIORVALUE() functions.
2) The record is cloned and updated with the new desired values (including calculating formula fields). These values can be obtained from a trigger with trigger.new.
2a) System validations are executed for the new values. It performs only system validations (required fields can’t be null, Numeric fields can’t have string values …) and UI validations (page layouts can make a field required or read-only). This whole step is skipped if the request is not from a Page Layout.
3) Execute the before triggers. As you know, this triggers allow you to make changes to field values, so the we must…
4) Validate the record. This step will execute most system validation again (except for the requirements made on a page layout), but most important this is where the custom validation rules are executed (for the first, and only time)
5) Save the record to the database, but do not commit. This step is where the system fields (CreatedDate, LastModifiedById, ID for new records, Opportunity. IsWon, Case. IsClosed …) populated, so we could now…
6) Execute the after triggers.
As you know there are some things that we haven’t mention, like workflows, Roll-up Summary Fields, Sharing Rules…. In what order do we execute them?
AR WE RUShD?
7) Executes Assignment rules, which assign Leads or Cases to users or queues based on the criteria specified automatically.
8) Executes auto-Response rules, which send automatic email responses when creating Leads (Web-to-Lead) or Cases (Self-Service portal, Customer Portal, Web-to-Case, Email-to-Case) based on the criteria specified.
9) Executes Workflow rules, which automates the following types of actions (create a new task, send an email, update a field, or notify external web services via SOAP messages). If there are field updates which make a change on a field (if the field value is a 5, and it is setting it to 5, you are not making any changes), then the record gets updated again firing the before update triggers, the after update triggers and the system validations. You must understand that custom validation rules are NOT fired again. So with a field update, you can set a field to an invalid value which is sometimes very useful.
10) On the documentation the step describe above is broken into steps 9, 10, and 11 ;-)
11) On the documentation the step describe above is broken into steps 9, 10, and 11 ;-)
12) Executes Escalation rules, which allow you to define automated actions when cases with specific criteria are open after a specified period of time.
13) If the record contains a Roll-up summary field or is part of a cross-object workflow field update, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure.
14) Go Up to the parent: If the parent record is updated, and a grand-parent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Grand-parent record goes through save procedure.
15) Executes Criteria Based Sharing evaluation, which allows you to make automatic exceptions (to grant wider access to data, not to restrict access) to your organization-wide sharing settings for defined sets of users.
16) Commits to Database all DML operations.
17) After all this is done, executes post-commit logic (sending email, and workflow outbound notifications).