Order of Execution in Salesforce

Order of Execution in Salesforce is very important for every developer. When on one object we have trigger, Process builder, Flow exist, then it is kinda necessary to know Order of Execution of them. Because without it either we didn’t get expected output or we overwrite the values.

Before Salesforce executes these events on the server, the browser runs JavaScript validation if the record contains any dependent picklist fields. The validation limits each dependent picklist field to its available values. No other validation occurs on the client side.
If we have any custom JS code validation they are also execute before it. Once all JS validations are completed server side processing is started.

When record get created into Salesforce following Order of execution works:

1. System Validation Rules
2. Record trigger flow and Apex Before Triggers
3. Custom Validation Rules
4. Duplicate Rules
5. Apex After Triggers
6. Assignment Rules
7. Auto-Response Rules
8. Workflow Rules
9. Processes
10. Escalation Rules
11. Roll-Up Summary Fields

Now we will check Trigger Order Of Execution

So on the server side:

1. Loads the original record from the database or initializes the record for an upsert statement.
2. Loads the new record field values from the request and overwrites the old values.
   If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
   Compliance with layout-specific rules
   Required values at the layout level and field-definition level
   Valid field formats
   Maximum field length
   When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Before executing a trigger, Salesforce verifies that any custom foreign keys do not refer to the object itself.
   Salesforce runs user-defined validation rules if multiline items were created, such as quote line items and opportunity line items.
3. Executes flows that make before-save updates.
4. Executes all before triggers.
5. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn’t run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
6. Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.
7. Saves the record to the database, but doesn’t commit yet.
8. After that it will executes all after triggers.
9. then executes assignment rules.
10. Executes auto-response rules.
11. Executes workflow rules.
12. If there are workflow field updates, updates the record again.
13. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules, flows, duplicate rules, processes, and escalation rules are not run again.
    Executes processes and flows launched via processes and flow trigger workflow actions.
14. When a process or flow executes a DML operation, the affected record goes through the save procedure.
15. Executes escalation rules.
16. Executes entitlement rules.
17. 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 procedure.
18. If the parent record is updated, and a grandparent 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 grandparent record. Grandparent record goes through save procedure.
19. Executes Criteria Based Sharing evaluation.
20. Commits all DML operations to the database.
21. Executes post-commit logic, such as sending email.

Here you will notice a new entry on point 3. In Spring 20 Salesforce announce Flow that can make before save update. They are similar to before triggers with some limitations.

Now we will review some of the comman Use cases here

Q: What will be the Order of Execution in case we have multiple triggers on single object?

A: We can decide or control their execution order here. So to avoid these types of situation we should always follow One Trigger One Object policy.

Q: If an object has multiple active flows that make before-save updates, What will be there Order of Execution

A: As they are same as trigger so we cannot control there order of execution.

Q: Can we bypass Validation rules if user don’t enter the value in one of the field?

A: Yes we can. So we can use before trigger or before save flow.

You can refer Salesforce official documentation here.

So this is Order of Execution in Salesforce. One should always remember it if we want to save ourself from some trouble. Do you want to add anything here, let me know in comments. Happy Programming 🙂