Salesforce order of execution..!
Salesforce has a bunch of rules that can be defined on objects and fields. For example, you can define validation rules, workflow rules, process builder, flows, assignment rules, escalation rules, auto-response rules, triggers etc.
When you save a record with an insert, update, or upsert statement, Salesforce performs the following events in order.
Order of execution is a set of rules that describe the path a record takes through all automations and the events that happen when you save a record with an insert, update, or upsert statement.
Here is order of execution in salesforce
- Record is being loaded from the database.
- System Validation will takes place
- Some of the record-triggered flows which need to be checked before saving a recoed
- All before triggers will be executed .
- Custom Validation rules.
- Executes duplicate rules.
- Partial saving (Saves the record to the database, but doesn’t commit yet.)
- All after triggers will execute.
- Assignment rules will come into action .
- Auto-response rules
- Executes some of the given workflow rules.
- Escalation rules will be taken place.
- If there are any workflow field updates,then once again updates the record.
- Entitlement rules.
- Criteria Based Sharing evaluation.
- Commits all DML operations
- post-commit logic
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. DML calls allow partial success when you set the allOrNone parameter of a Database DML method to false or when you call the SOAP API with default settings.
Let's us see some technique to remember the rules in a simpler way :