Order of Execution in Salesforces in 15 Easy Steps || interview stuff

Order of Execution in Salesforces in 15 Easy Steps

It's always important to keep the order of events which salesforce execute when any DML statement that is insert, update, or upsert statement occurs on any record.

Below is an Order of Execution in Salesforce:

---

• 1. System Validation Rules.
  2. Executes all before triggers.
  3. Custom Validation rules. 
  4. Executes all after triggers.
  5. Executes assignment rules.
  6. Executes auto-response rules.
  7. Executes workflow rules.
  8. If there are workflow field updates, updates the record again.
  9. If the record was updated with workflow field updates, fires before and after triggers one more time. Custom validation rules are not run again.
  10. Execute Process Builders.
  11. Executes escalation rules.
  12. If the 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. Parent record goes through save process.
  13. 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 process.
  14. Executes Criteria Based Sharing evaluation.
  15. Commits all DML operations to the database.
  
  16. Executes post-commit logic such as Sending email.

Being aware of this sequence will help you configure your apps correctly and troubleshoot.

Additional Considerations:

---

Please note the following when working with triggers.

• The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event.

         For example, if you have two before insert triggers for Case, and a new Case record 
         is inserted that fires the two triggers, the order in which these triggers fire isn’t
         guaranteed.

• When a DML call is made with partial success allowed, more than one attempt can be made to save the successful records if the initial attempt results in errors for some records.

         For example, an error can occur for a record when a user-validation rule fails.
         Triggers are fired during the first attempt and are fired again during subsequent
         attempts. Because these trigger invocations are part of the same transaction, 
         static class variables that are accessed by the trigger aren't reset.

• Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the version of the object immediately prior to the workflow update, but the object before the initial update was made.

         For example, suppose an existing record has a number field with an initial value of 1.
         A user updates this field to 10, and a workflow rule field update fires and increments it
         to 11. In the update trigger that fires after the workflow field update, the field value of 
         the object obtained from Trigger.old is the original value of 1, rather than 10, 
         as would typically be the case.

If you are running into issues where the system is not behaving the way you expect it to, the best way to diagnose and troubleshoot will be to turn the debug on.

To set debug log follow below steps

• Go to Setup
• Then go to Monitor
• Expand Logs
• And then select Debug logs.
• Click on New button
• Select User from user lookup for which you have to capture the debug logs
• Select start date and end date for debug. (You can select maximum 1 day for per user)
• Select the debug level from lookup. You can create new debug level with appropriate filters.
• Click Save button.

For simplification I can say it as Go to Setup -> Monitor -> Logs -> Debug Logs

Now execute the transaction and then check the debug log.