Salesforce order of execution: steps and examples

In this post, we’ll cover Salesforce’s order of execution and the different steps in the execution process.

What is the Salesforce order of execution?

Salesforce order of execution refers to the sequence of different logic that is executed when creating, updating, or deleting a record.

Salesforce has a well-defined sequence of events that occur during the processing of these actions to ensure data consistency and maintain the platform’s integrity.

However, before Salesforce executes the steps, the browser performs JavaScript validation to determine whether the record includes any dependent picklist fields. This validation restricts each dependent picklist field to its valid values. That’s the only validation on the client side.

Components of the order of execution

Salesforce’s order of execution involves various components and phases that determine the sequence in which operations, triggers, processes, and automation execute. The key components of Salesforce’s order of execution include:

1. Record initialization

Salesforce loads the original record from the database or prepares a new record for an upsert operation (when rows are inserted into a database table if they do not already exist or updated if they do).

Salesforce’s order of execution involves various components and phases that determine the sequence in which operations, triggers, processes, and automation execute.

2. Field value update

New field values from the request overwrite the old values.

3. System validation rules

These rules enforce fundamental data integrity checks, such as required fields, valid field format, maximum field length, and unique field values.

In other cases, it validates only foreign keys and checks for self-referencing custom foreign keys. If multiline items exist (e.g., quote line items), Salesforce runs custom validation rules.

4. Before record-triggered flows

Salesforce allows you to leverage Flow Builder to declaratively create automated business logic using clicks and not code. Before record-triggered flows execute before saving a record.

5. Run all before triggers

Before triggers are Apex code that executes before records are saved to the database. Use before triggers to modify record data before it’s committed.

6. Validation recheck

System validation repeats for required fields with non-null values. Custom validation rules are executed again.

7. Duplicate rules

Duplicate rules prevent the creation of duplicate records.

8. Record save

The record is saved but not committed to the database.

9. Run all after triggers

An after trigger executes after any change to a record, including changes made by other triggers. For example, you could use an after trigger to automatically update related records when a record changes.

10. Assignment rules

Assignment rules assign ownership of records (e.g., leads for prospective customers, or cases for after-sales service) to specific users or queues based on predefined criteria.

11. Auto-response rules

Auto-response rules send automated email responses to prospects or customers based on specific conditions.

12. Workflow rules with field updates

Workflow rules automate internal processes by defining criteria and executing specified actions, such as updating fields or sending email alerts. Both before and after update triggers will execute again, but for the final time, irrespective of the insert or update operation on the record.

13. Escalation rules

Escalation rules automatically escalate cases to higher levels of support depending on the criteria.

14. Processes and flows

Processes and flows automate actions based on specified criteria. They can include both auto-launched and record-triggered processes. Processes and flows execute after before triggers.

15. Entitlement rules

Entitlement rules outline the steps needed to resolve a case.

16. Roll-up summary fields (parent and grandparent)

If applicable, these are used to calculate and update values from related records, such as those in parent and grandparent records.

17. Criteria-based sharing evaluation

Sharing rules are evaluated based on criteria.

18. Database commit

All DML operations, including inserts, updates, and deletes, are committed to the database.

19. Post-commit logic

Executes post-commit logic after saving changes, such as sending emails and executing asynchronous Apex jobs (e.g., queueable jobs and future methods).

You should note that steps from assignment rules to the roll-up summary field are skipped during a recursive save.

Building dependable, effective Salesforce automations requires an understanding of the order of execution and the evolution of flow behavior.

Key changes to flow behavior and execution order (Spring ’22)

Building dependable, effective Salesforce automations requires an understanding of the order of execution and the evolution of flow behavior. The most crucial factors and adjustments you should be aware of are listed below.

After-save flows now run before workflow rules

Before, record-triggered flows were executed after workflow rules. This has changed. After-save flows now run before workflow rules for flows on API version 54.0 or later.

Workflows are now more consistent with Apex triggers, as after-save Apex triggers have always executed before workflows. This ensures workflows don’t clobber changes made by flows and makes automation ordering simpler.

You can now specify the order for multiple flows

Prior to this, if you had, say, three record-triggered flows (e.g., three “after-save” flows) on the same object, they would execute in an unpredictable sequence, most likely by creation date. This led to “mega-flows” containing all the logic to ensure the proper order of execution.

You can now set the Trigger Order property between 1 and 2,000 for all before-save or after-save flows. Now you can divide complex automation into smaller flows with single responsibilities owned by separate teams and explicitly specify the order of execution.

This allows for modular development, simplifies maintenance, and helps diagnose problems.

Scheduled flows wait for the transaction to commit

Until now, scheduled flows could start running before the data from the triggering transaction was committed to the database. This could only lead to flows reading out-of-date data or working on uncommitted transactions.

The change means scheduled flows are now executed after the transaction has been committed. This ensures data changes have been committed before the scheduled flow’s logic is executed, thus enhancing data integrity and consistency.

Flow entry conditions get evaluated immediately

Previously, flows could run even if they didn’t completely evaluate entry conditions upon entry. Since Spring ’22, the entry conditions for record-triggered flows are evaluated at the beginning (just like validation rules).

This ensures that the system executes flows only when certain conditions are met, improving efficiency and avoiding unwanted executions.

Flow trigger explorer introduced

Before the flow trigger explorer was introduced, providing a “single source of truth” for record-triggered flows and orchestrations on a given object and event (e.g., “Account – before save”).

Before the flow trigger explorer’s introduction, admins needed to track which flows were enabled for each object. The trigger explorer gives you a high-level view of all triggered automation on an object, allows you to turn flows on/off in one place, and displays flow versions and trigger order values.

Field updates from time-based workflows trigger flows

Time-based workflow rule field updates and approval process field updates now run before-save and after-save record-triggered flows. Initially, time-based updates did not trigger flows, leading to different automation behavior.

But later time-based field updates are treated like save operations—they trigger flows. Flows now execute slightly more frequently, but automation results are consistent with both field updates from users and triggers, and time-based workflow field updates.

Salesforce order of execution and record locking

As various processes, triggers, and automation execute during record operations, record locking ensures that multiple users or processes don’t modify the same record simultaneously. This is because it could lead to data conflicts and inconsistencies.

When Salesforce processes updated records according to the order of execution, it takes record locking into account to prevent data conflicts.

For example, when a before trigger modifies a record, it locks the record. As a result, other triggers, workflows, or processes only execute after the before trigger. Record locking ensures data consistency and prevents race conditions.

Record locking ensures data consistency and prevents race conditions.

Role of Apex in Salesforce’s order of execution

Apex is at the programmable heart of Salesforce’s runtime order of execution. It is the place where you can explicitly take control when declarative tools like flows or validation rules are insufficient. It operates within the same transaction that the database is writing to.

It’s most noticeable in the flow via triggers, which run either before or after a record is saved.

In the before triggers, Apex code is perfect for performing complex validation, setting field defaults, or manipulating data without additional DML statements.

Since triggers fire after the database write, Apex code enables you to run operations that require the ID or any other operations that require a record to be saved to the database.

Apex also communicates with other automation tools. It can be called from flows, or even from external systems, and therefore is often the “last line of defense” when declarative automation reaches its limits.

However, when writing Apex code, be aware of the execution order to prevent duplication, recursion, or conflicting record changes.

Which is why Paul Battisson (author of Mastering Apex Programming) believes, “The Salesforce order of execution should be one of the first things taught to every administrator or developer working on the platform.”

Importance of Salesforce’s order of execution

While Salesforce’s order of execution is necessary, below are reasons why it is important:

1. Stops data from getting corrupted by conflicting automation

The order of execution defines the order in which validation rules, flows, triggers, and workflows are executed when a record is saved. Without order, two automations may attempt to change the value of a field in different ways, resulting in an unexpected end result or leading to corrupt data.

2. Enables predictable debugging

The order of execution serves as a blueprint for when a save is unsuccessful or when conditions are not met. There is more than one source of error. In the absence of a sequence, it’s like shooting in the dark. With the sequence, you can exclude things.

3. Improves performance and governor limit hits

The order of execution affects how many times the database is accessed, how many queries are executed, and when asynchronous jobs are triggered.

Salesforce has very tight governor limits. Without understanding the order, you can easily blow out these limits by causing re-saves or running queries too soon.

4. Guarantees the consistency of related data

The order of execution defines when parent, child, and roll-up summary fields are up-to-date. When you change a child record (such as an Opportunity), the parent Account’s roll-up summary fields (such as Total Opportunity Amount) do not immediately reflect the change.

If your automation attempts to read that summary too soon, it will be using outdated data and make the wrong decisions.

5. Allows testing of behavior

The order of execution helps provide a blueprint for Salesforce testing. You can test that not just a record was saved, but that an automation occurred at a particular time. If there is no order, you can’t create deterministic tests.

You may get a test that passes 90% of the time, but fails 10% due to two automations running in parallel. With order, you know what will happen in all cases.

If you convert a workflow rule to a flow without knowing that flows run earlier in the order of execution, you might break other logic.

6. Safe to migrate from old automation

There have been changes to the order of execution over time. For example, with the recent changes, the after-save flows preceded workflow rules. Understanding these changes can help you safely migrate from process builder and workflow rules to flow.

If you convert a workflow rule to a flow without knowing that flows run earlier in the order of execution, you might break other logic.

For instance, a second workflow rule might have depended on the first workflow rule to change a field, but after migration, the flow runs earlier, and the second workflow rule can’t find the field update.

Troubleshooting and debugging Salesforce order of execution issues

Troubleshooting the order of execution in Salesforce helps ensure your automation, triggers, processes, and workflows behave as expected. Below are some steps to take when troubleshooting.

1. Enable debug logs

Salesforce provides debug logs that capture detailed information about the order of execution for a specific transaction. Review the debug logs to see which processes, triggers, and validations are firing and what data they are processing. Look for error messages or unexpected behavior.

2. Analyze error messages

If there are error messages in the debug logs or on the user interface, carefully analyze them. Error messages often provide clues about what went wrong. Pay attention to custom validation rule errors, trigger failures, or workflow rule errors.

3. Review trigger logic

Examine the logic within your triggers, processes, and workflows. Correctly define conditions and sequences. Check for any logical errors, infinite loops, or recursion in your Apex triggers.

4. Consult the Salesforce community about order of operation issues

If you cannot identify the issue independently, consider seeking help from the Salesforce Trailblazer community or Salesforce support.

Best practices for managing Salesforce order of execution

Best practices for managing Salesforce’s order of execution involve optimizing your processes, triggers, and automation to ensure efficient and reliable data handling. By adhering to these practices, you can avoid conflicts, maintain data integrity, and create a more streamlined user experience.

1. Plan your process logic carefully

Before implementing automation, thoroughly plan the logic of your processes, triggers, and workflows. Consider the sequence of events and the impact of each action on the data. This proactive approach minimizes conflicts and unexpected outcomes.

2. Use bulk processing techniques

Design your triggers and processes to handle multiple records simultaneously (bulk processing). This reduces the number of times triggers and processes fire, optimizing performance, and reducing the potential for record locking.

Design your triggers and processes to handle multiple records simultaneously (bulk processing).

3. Minimize trigger logic

Keep trigger logic focused on specific tasks and avoid unnecessary complexity. Splitting triggers based on actions (e.g., before insert, before update) can help maintain clarity and manage the order of execution.

4. Limit the use of recursive triggers

Recursive triggers occur when a trigger update causes another trigger to fire, leading to a loop. Use design patterns like a static variable to prevent unnecessary recursion.

5. Prioritize record locking best practices

Structure your automation to minimize conflicts by locking records for the shortest duration possible. Use FOR UPDATE SOQL queries to explicitly lock records when needed, ensuring that your code is aware of and respects record locks. Avoid long-running or complex operations within locked record contexts.

Structure your automation to minimize conflicts by locking records for the shortest duration possible.

6. Thoroughly test your automation

Before deploying automation to production, thoroughly test its behavior in a sandbox or development environment. This testing helps uncover issues related to the order of execution, logic conflicts, and performance.

7. Stay updated with Salesforce releases

Stay informed about new Salesforce releases and changes to the order of execution. Salesforce’s updates can introduce changes that affect your existing automation, so staying current is critical.

Limitations of Salesforce’s order of execution

Salesforce has a few limitations that businesses should consider before adopting the tool. In this section, we’ll discuss a few of the considerations you should make before adopting Salesforce.

1. Cost

As a tool, Salesforce is expensive, involving extensive licensing fees and customization options. Add-ons can also be expensive, making the tool less accessible for businesses with a small budget.

2. Setup

Setting up Salesforce is complex, often requiring professional help. Staff also need special training in order to use the program properly.

3. Flexibility

Salesforce lacks flexibility, making it difficult to modify the predefined order of execution.

4. Needs extra logic

Salesforce also lacks built-in recursion prevention, requiring extra logic to avoid infinite loops. These limitations necessitate careful design to ensure smooth and efficient automation.

5. Control

If you have multiple Apex triggers on the same object and event, such as two before update triggers on an account, you can’t control the order in which they execute. It will be random.

A workflow rule that does a field update causes a re-save that runs before triggers and after triggers again, but not validation rules or duplicate rules.

6. Hidden recursion

A workflow rule that does a field update causes a re-save that runs before triggers and after triggers again, but not validation rules or duplicate rules. This “hidden recursion” can unexpectedly consume governor limits.

7. No way to specify orders

There’s no way to specify that a flow runs before a trigger in the same category (before or after). They must run in the following order: before-save flows before before triggers, and after triggers before after-save flows.

8. Unknown roll-up source

A roll-up summary field update on a parent record triggers a full order of execution to occur on that parent record, but there is no built-in mechanism to tell whether this update was triggered by a roll-up recalculation or a user.

9. Before-save limitations

Before-save flows can only update the current record. Also, before-save flows can’t create, update, or delete related records, so you must use after-save flows or triggers for cross-object operations.

10. Roll-up timing

Roll-up summary fields are updated after triggers, flows, and workflows have fired. You can’t access the new roll-up value until after the transaction is complete.

11. Validation timing

Validation rules are evaluated before-after triggers and after-save flows. As a consequence, validation rules cannot access changes made by after triggers and after-save flows during a save operation.

12. Async events

Platform event triggers run asynchronously in a separate transaction from the save that triggered the event. So you can’t use them for real-time validation, data consistency within the same transaction, or access the original trigger context.

Operations that don’t invoke triggers

Not all operations result in a trigger; some bypass trigger evaluation. Here’s a list:

1. Cascading deletes: When a record that owns other records is deleted, and the system deletes the owned records, the children of the deleted record do not initiate the delete.
2. Formula field updates: Formula fields are calculated at retrieve time—no record is updated in the database and no triggers are fired.
3. Roll-up summary field updates: These are calculated by the system and don’t represent a DML operation on the records.
4. Data export operations: Bulk data export operations do not go through the save process.
5. Report data access: Data read for reporting purposes does not update records, so triggers don’t fire.
6. Manual sharing changes: Sharing rule calculations update the sharing table, not the record.

Wrapping up

To ensure your Salesforce automation aligns with the platform’s order of execution, careful planning and continuous testing are crucial. Tricentis Salesforce offers a powerful solution for automating these tests with its AI-driven platform, designed to adapt to Salesforce’s complexities.

By simplifying the creation and maintenance of automated tests, Tricentis helps prevent conflicts, maintain data integrity, and optimize the efficiency of your Salesforce processes. Consider exploring Tricentis’ capabilities through their free trial to enhance the quality of your Salesforce automation.