What is the Order of Execution in Salesforce?

As per Gartner, revenue in the Enterprise Software segment is expected to reach more than US$230 million by the end of 2021. Businesses are shifting more and more towards technological CRMs to keep up in today’s tech era.

Salesforce has a bunch of rules that can be defined on objects and fields. For example, you can define validation rules, escalation rules, auto-response rules, triggers, workflow rules, and different types of flows in Salesforce to automate business processes. These automation capabilities empower users to streamline and optimize their workflows, ensuring efficient data management and enhanced user experience.

If you are a Salesforce consultant, developer, or architect, it’s essential for you to understand the order in which the rules and triggers are executed. Let’s see the order of execution in Salesforce.

Watch this Salesforce Training video to learn more about salesforce concepts.

Order of Execution in Salesforce Explained

Order of Execution in Salesforce is nothing but a set of rules that govern, or describe the path of a record while it travels through multiple automation and events happening from SAVE to COMMIT. In simpler terms, when you save a record by giving the insert, update, or upsert statement, Salesforce performs certain events in an orderly manner. This is termed the order of execution in Salesforce. The order of execution starts with a DML operation and later there are further involvements like triggers, out-of-the-box Salesforce components, workflows, different rules, etc.

Steps of Order of Execution in Salesforce

The sequence of steps mentioned below outlines the order of execution in Salesforce when a record is being processed and saved. Each step occurs in a specific order, and the execution order is crucial for maintaining data integrity and ensuring that various validations, rules, and automations are applied correctly. The order of execution is as follows:

1. Load the original record from the database and load the record for the upsert statement.
2. Load the new record field values from the request and overwrite the old values.
   If the request comes 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
3. Whenever a request comes from other sources, e.g., Apex application or a SOAP API call, Salesforce validates only the foreign keys.
4. Executes record-triggered flows that are configured to run before the record is saved.
5. Executes all before triggers.
6. Run most system validation steps. Verify that all required fields have a non-null value and run user-defined validation rules.
7. Executes duplicate rules.
8. Saves the record to the database, but doesn’t commit yet.
9. Executes all after triggers.
10. Executes assignment rules.
11. Executes auto-response rules.
12. Executes workflow rules.
13. Executes escalation rules.
14. If there are workflow field updates, update the record again.
15. If the record was updated with workflow field updates, fires before update triggers and after update trigger one more time (and only one more time), in addition to standard validations.
16. Executes processes and flows launched using flow trigger workflow actions.
17. Executes entitlement rules.
18. Executes record-triggered flows that are configured to run after the record is saved.
19. If the record contains a roll-up summary field or is part of a cross-object workflow, perform calculations and update the roll-up summary field in the parent record. Parent record goes through the save procedure.
20. 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.
21. Executes Criteria Based Sharing evaluation.
22. Commits all DML operations to the database.
23. Executes post-commit logic, such as sending an email.

After Commit Logic: Actions in the After-Data-Change Phase

The actions mentioned below are part of the broader “after commit logic” that takes place once the data changes are permanent after the order of execution.

1. All emails are sent
2. Asynchronous apex: @future
3. Processes Async Sharing Rule
4. Queues outbound messages
5. Calculates index
6. Renders previews for files
7. If Platform Events are configured, they are published

Triggers in Salesforce

The two types of Triggers in Salesforce are as follows:

• Before Triggers – These are executed before the record values are saved to the database.
• After Triggers – These are used to trigger records that are read-only.

Before or after applying changes to the Salesforce record, you can make customized changes to it. This is enabled by triggers. Triggers can invoke apex. Triggers are executed before or after these operations:

• undelete
• upsert
• merge
• delete
• update
• Insert

Some top-level objects like Account, support triggers. You can define triggers for them. If you want to define a trigger, you can go to that particular object Object Management Settings and go to Triggers.

Which Operations Don’t Invoke Triggers?

The steps listed below are related to various scenarios and conditions that can impact the execution of triggers in Salesforce. While they do not follow a specific sequence like the order of execution during record processing and saving, they outline different situations in which triggers may or may not be invoked. These scenarios involve specific conditions or actions that might affect the behavior of triggers.

• All the records that didn’t start a delete, don’t invoke triggers
• Child records that have been reparented using the merge operation
• Huge email actions, division transfers, address updates
• Custom field data being modified
• When you rename or replace a picklist
• When you change a user’s division that is the default, while the transfer division option is checked
• Price book management
• Update account trigger won’t work before/after a user’s account is changed to a business one
• When the LikeCount counter increases, update triggers won’t work on FeedItem

Extra Consideration

When you have multiple triggers for the same object due to the same event, the execution of that trigger is not guaranteed. You’ll need to implement Trigger Framework in this case.

Conclusion

As we have discussed in order of execution there is a lot more to understand than triggers run before workflows. Understanding the flow and apps will have more scalability and reliability.