Official Order Of Execution In Salesforce With Diagram

The execution order in Salesforce can be very confusing when first learning about it.

However, to be a successful Salesforce professional, you must have a solid understanding of the functionality.

Salesforce’s order of execution will surely come up in any Salesforce developer interview, and it is essential to figure out why you are getting unexpected automation outcomes.

In this blog, I will walk you through the execution order, explain all the steps and when they occur, and give you the best resources available to help you master the concept.

Ready to roll? Read on.

Salesforce Order Of Execution Diagram

Grasping the order of execution in Salesforce is not just a technical detail. It’s a crucial step towards error-free and efficient workflows.

Before I cover all the steps, check out the official diagram of how Salesforce executes events when you save a record with an insert, update, or upsert.

Don’t forget, you can always download a copy of this official diagram for quick and easy reference in your Salesforce journey.

Source

What Is The Order Of Execution In Salesforce?

The execution order in Salesforce is a record’s path when saving using an insert, upsert, or update operation.

It includes all the automations and events that are executed or calculated from the time the record is saved to the time it is committed to the database.

The Salesforce order of execution has 20 distinct steps, all of which are run on the server side. The only client-side validations that take place are picklist dependencies.

1. Loads the original record

When you change an existing record in the database, the original record is loaded. When creating a new record, it is initialized for an upsert.

2. Loads the new record values

The new values the request defines are loaded, and the old record values are overwritten.

If the request was made from a standard UI element, then system validations are run for the following:

• Layout-specific rules (i.e., field dependencies)
• Required fields
• Field formatting (i.e., email and phone number formats)
• Maximum field length

Only the foreign keys are validated when the request is not made from a standard UI element. Then, before executing a trigger, custom foreign keys are checked to ensure there are no self-references to the object of the record.

The system then checks to see if multi-line items were created or if a request from a user record was made from a standard UI page.

When multi-line items are created, then the custom validation rules are run.

3. Executes “before save” record triggered flows

Record triggered flows that are executed “before save” are executed.

An example of this is a flow that is optimized for “Fast Field Updates.”

4. Executes all before triggers

All the remaining before triggers are fired. This would include your custom APEX before triggers that update or validate record values.

5. Runs most system validation steps again

Next, most of the system validation rules are rerun.

You might wonder what is not included. Layout-specific validations are not rerun when the request is from a standard UI edit page.

As mentioned above, this would consist of:

• Layout-specific rules (i.e., field dependencies)
• Required fields
• Field formatting (i.e., email and phone number formats)
• Field length

Custom validation rules are rerun, and the system ensures that all required fields are not blank.

6. Executes duplicate rules

All the standard and custom duplicate rules are executed.

The process ends, and the record is not saved if any duplicates match your defined rules.

If all the duplicate rules pass, the process continues to the next step.

7. Saves the record to the database

The record is saved to the database if no duplicates are detected based on your duplicate rules.

It is important to note that Salesforce has not yet committed these changes to the database. This means your changes are only visible within your transaction scope and can be rolled back if needed.

Once your record changes have been committed to the database, they are permanent. Changes cannot be rolled back since all save points have been erased, record locks are removed, and the transaction is considered complete.

8. Executes all after triggers

All the after triggers are run once the record is saved to the database. This would be your custom APEX triggers.

If the save is recursive, Salesforce will skip steps 9-17 to avoid an infinite loop. When the save is not recursive, the execution order runs the assignment rules.

9. Executes assignment rules

Any active and valid assignment rules are executed to automate record ownership changes. Assignment rules can be defined for Leads, Cases, and Topics.

10. Executes auto-response rules

Next, any auto-response rules configured to send when leads are captured or cases submitted are run.

11. Executes workflow rules

Workflow rules are executed after auto-response rules.

Workflow rules can be used to:

• Automate task assignments
• Send email alerts
• Update field values
• Send outbound messages

If the workflow rule updates a field, the record is updated again. As such, system validations are also rerun. Before and after triggers are also rerun once. The triggers do not run again after this.

Note: When workflow rules update a field, custom validation rules, flows, duplicate rules, processes, and escalation rules are not rerun.

12. Executes escalation rules

After workflow rules, escalation rules are run. Escalation rules are used in case management to update the case owner and/or send a Salesforce notification to users.

13. Executes flow automations

Flow automations are executed in random order. This includes processes, flows launched by processes, and flows launched by workflow rules.

14. Executes “after save” record triggered flows

“After save” record triggered flows will run next. These record-trigged flows are the flows optimized for “Actions and Related Records.”

15. Executes entitlement rules

Entitlement rules are executed once the “after save” record trigger flows are run. These actions are related to your entitlement processes.

16. Calculate roll-up summary fields on parent records

If the record has roll-up summary fields, the roll-up summary fields on the parent records are calculated. When no rollup summary fields exist on the record, steps 16 and 17 are skipped, and criteria-based sharing rules are executed.

17. Calculates roll-up summary fields on grand-parent records

If the record has roll-up summary fields, the roll-up summary fields on the grandparent records are calculated.

18. Executes criteria-based sharing rules

Next, criteria-based sharing rules are executed to give additional users access to records if any field updates meet the criteria.

19. Commits all DML operations to the database

The record is then committed to the database, and the changes are permanent. Changes cannot be rolled back since all save points have been erased, record locks are removed, and the transaction is considered complete.

20. Executes post-commit logic

Finally, any post-commit logic is executed once all DML operations are committed to the database.

This includes operations like sending emails, asynchronous APEX jobs, future methods, and asynchronous paths stemming from record-triggered flows.

Why Do You Need To Know The Order Of Execution In Salesforce?

Now that you have been briefed on the order of execution in Salesforce, you might be asking: But why does it even matter?

Understanding the Salesforce order of execution helps you debug unexpected behavior, ensure your Salesforce solution design works as expected, and prepares you for Salesforce interviews.

Want to learn more about how exactly this is true?

Check it out below.

1. Debugging and understanding unexpected behavior

Unexpected outcomes can occur frequently when automating Salesforce. Knowing the order of execution in Salesforce is the key to understanding why this unexpected behavior occurs.

When testing automation in Salesforce, you might encounter missing or duplicate records or even blank or incorrectly populated fields that differ from what you expect.

For example, you have a validation rule that prevents users from updating a closed case. But you also have an automation that auto-populates a field on case records.

If your record-triggered flow is configured to run after the record is saved, then your validation rule will block you from the automation from updating the case, causing the end user to see an error message.

By knowing the order of execution in Salesforce, you can identify this and update your record-trigger flow to run before the record is saved to ensure your behavior runs smoothly.

2. Identifying why limits are being exceeded

Limits are another significant consideration when using the Salesforce platform. Your automations might cause CPU time limit exceptions or attempt to run too many SOQL queries. Knowing the execution order in Salesforce will expedite your debugging process so you can figure out the root of what is causing your automations to exceed Salesforce governor limits.

3. Design considerations

When designing Salesforce solutions, knowing the order of execution is a must. Automations that action records could behave differently depending on when the automation is executed, and this must be accounted for in your solution design. Additionally, if you need triggers or logic to run in a specific order, knowing the impact of Salesforce’s order of execution will help guide how you design your solution.

4. Interview questions

If you are looking to get hired in a more technical Salesforce role, such as a developer or architect, you might be asked questions where you need to know the order of execution in Salesforce. As you work with the Salesforce platform, ensure you know the execution order to answer these types of interview questions.

Salesforce Order Of Execution Components

Knowing the Salesforce order of execution is great, but knowing what all the operations do within the order of execution is even better.

Below is a high-level overview of the components involved in the Salesforce order of execution.

Component	Description
DML operations	Data Manipulation Language that is used to make changes to your Salesforce database.
Record triggered flows	Automations that happen behind the scenes when a record is created, updated, or deleted.
APEX triggers	Custom actions are defined to execute before or after a record is created using APEX code.
Duplicate rules	Rules that define what should happen when a user views or tries to create a duplicate record.
Assignment rules	Define who should be assigned a lead or case based on specific criteria.
Auto-response rules	Send auto-response emails to lead and case submissions.
Workflow rules	Rules that automate internal processes in your Org. New Workflow rules can no longer be created as of Winter ‘23.
Escalation rules	Defines when a case should be escalated and what happens when a case is escalated.
Flows	Point-and-click automations used to eliminate manual work for Salesforce users.
Entitlement processes	Timeline and associated actions reps must do to resolve support records (cases).
Roll up summary field	A field that aggregates data from child records.
Sharing rules	Rules that grant record-level access to users based on defined criteria.

Summing It Up

Understanding the Salesforce Order of Execution is essential for ensuring seamless and error-free workflows.

This knowledge helps debug and optimize your Salesforce Org and is crucial for interviews and project design. Mastery of the Salesforce execution order will elevate your impact within any project or organization.

Ready to advance your Salesforce skills even further?

Join my exclusive email list to access premium content, including in-depth guides and expert insights that keep you ahead in the Salesforce landscape.

Don’t miss out on the opportunity to advance your career—subscribe Now!

Frequently Asked Questions (FAQs)

Which executes first: trigger or flow?

Record-triggered flows are executed before triggers. Before record-triggered flows execute before “before triggers.” After record-triggered flows execute before “after triggers.”

What is the order in which Salesforce events are executed when saving a record?

Salesforce events are triggered according to the Salesforce order of execution, which consists of 20 steps that outline the path of a record from save to commit.

How do I remember the order of execution in Salesforce?

To remember the order of execution in Salesforce, you need to review and study the order of execution process map, understand the Salesforce components involved in the execution order, and get hands-on experience troubleshooting issues related to the Salesforce order of execution.