Salesforce Order of Execution

In this chapter, we will explore the Order Of Execution (OOE) of how your system runs various tasks in the backend. OOE was critical in general only for technical teams in the past, but now it is more important for every Salesforce team member. As you know, flows are declarative and low-code and can be created by non-techies. Understanding the OOE with real-world examples will help you get comfortable, and this chapter will explore the concepts of execution by understanding how existing functionality will interact and affect new functionality and vice versa so as not to cause any technical debt.

In this chapter, we will cover the following sections to get a good grasp of Salesforce OOE:

• What is OOE?
• Salesforce Platform OOE
• Avoiding flow execution anti-patterns

Let us look at each of these in more detail.

What is OOE?

The OOE is a set of rules that describe the path your record takes through all available automation for a given object and all the events that happen from the user saving the record until the record is committed to the database.

When multiple automations such as workflows, assignment rules, escalation rules, roll-up summaries, and triggers are in place, it is crucial to know the sequence in which Salesforce processes these automations. The logical order in which the system processes these automation steps is termed the OOE.

We use software systems that help us create, read, update, and delete data many times a day. We all utilize SQL statements unknowingly every day, whether we’re hardcore developers, system administrators, or even business team members. A good example would be your reports. You select fields from an object, filter the data, group it, limit it, and so on. How do we ensure that we get accurate data in our queries when we run our reports? Through...

Salesforce Platform OOE

As with every other software application, Salesforce also defines its own set of OOE in its database. Without these rules and controls in place, we will run into unexpected behaviors in our data as well as the overall behavior and performance of the system, not to mention implications for your organization.

This is OOE as defined by Salesforce. No matter what kind of tool you use, this order needs to be followed. It can be your Apex coding, Salesforce flows, or something else.

This is the sequence in which Salesforce executes various tasks. When any DML operation is performed in a Salesforce record, such as your user clicking the Save button to create or update a record, the following is the OOE in Salesforce:

1. Initializes the record (the original record loaded from the database for updates).
2. System validation rules: Loads new values (for updates, old values are replaced). This event verifies field formats, maximum field lengths, required fields...

Avoiding flow execution anti-patterns

You may be wondering why this topic is discussed now and not at the end of the book. Here, I would like to emphasize that we need to plan for this right from the early phases of the project, even before any development of flows is started. You, as a builder of flows, need to understand this conceptually with reference to the business process flow. Make a note on your business process flow diagram (similar to the one in Figure 3.1) so that you can revisit it as the project progresses. We will revisit the same topic in Part 3 of this book.

Just because you would like to implement a cool tool (in this case, our all-powerful Flow Builder) does not necessarily mean you should use flows for everything. It may not always make sense to implement flows all the time. Let’s look at some anti-patterns that we tend to implement. Think through it and do some exploratory analysis before you jump to conclusions.

Screen flows are good to have for your...

Summary

In this chapter, we reviewed why OOE is not only important but also critical for designing and developing flow to meet your business needs. We also reviewed a few anti-patterns that you should keep an eye on and think about while designing, developing, and testing your flows.

Remember to consider the OOE for all automation done inside and outside your flows. If you have an Apex trigger and a flow on the same given object at the same time, you need to understand in which order these are executed.

In the next chapter, we will explore five basic types of flows to automate our business processes. You will gain a deep understanding of the scenarios for each of the flow types: screen flows, record trigger flows, schedule trigger flows, platform event-triggered flows, and autolaunched flows.

Questions

1. We have a case assignment rule before saving a record-triggered flow, and it happens both times to update the case owner. Who wins? The case assignment rule or the before-save record-triggered flow?
2. Do you have control over when a specific flow during the execution of Salesforce flow automation can run?
3. Why do we need to understand Salesforce OOE?
4. What happens when a roll-up summary field on parents gets updated? What happened to the OOE for this parent record?

Further reading

• Part 1 of The Salesforce Business Analyst Handbook
• Salesforce Platform-Order-Of-Execution-Diagram: https://architect.salesforce.com/1/asset/immutable/s/e6cf2ac/assets/images/Salesforce-Order-Of-Execution-Diagram.png
• Apex Developer Guide - Triggers and Order of Execution: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm
• Salesforce Ben-Learn Salesforce Order of Execution: https://www.salesforceben.com/learn-salesforce-order-of-execution/
• Guidelines for Defining the Run Order of Record-Triggered Flows for an Object (salesforce.com): https://help.salesforce.com/s/articleView?id=sf.flow_concepts_trigger_guidelines.htm&type=5
• Select (SQL): https://en.wikipedia.org/wiki/Select_(SQL)