When it comes to understanding how Salesforce operates, there are many factors to consider. One key aspect is the “Order of Execution”, or the sequence in which Salesforce automation runs. Knowing the order of execution can help you better understand how your code, triggers, flows, and other automation tools operate within the platform.
Whether you’re a seasoned Salesforce developer or new to the platform, understanding the Order of Execution is essential to maximising the system’s potential. But there are so many different automation types available, and do I need to consider all of them in all use cases?
This article might spark some heated debate, I am well aware! It delves into the topic of automation and how to choose the right tools for your organization while filtering out unnecessary automation and simplifying processes to reduce complexity. But don’t worry, and we’re not trying to stir the pot too much… just a little 😜. As software developers and architects, it’s essential to consider ways to streamline and improve our workflows constantly. Let’s dive in and start the conversation.
tl;dr - show me the diagram
For the impatient amongst us, here is the diagram showing the simplified representation of the “Order of Execution” based on the original diagram posted on the Salesforce Architects blog.
The complexity and nuances
Continuously changing
Small (or significant) changes happen to the “Order of Execution” over time. And details on each step can change, so make sure to re-evaluate this process with each new release – it might impact you more than you might think (in a good or bad way).
An excellent example between v55.0 and v56.0 is that the following warning has disappeared:
This is a great improvement, but warrants more investigation: “In what order are they executed then?“
An overview
When looking at all the different automation tools available within the Salesforce platform, it is easy to get overwhelmed. And that is not even considering the order they are executed in on the data.
- Workflow Rules (retiring)
- Process Builder (retiring)
- Flow Builder
- Apex
- Assignment Rules (Lead & Case)
- Escalation Rules (Case)
- Entitlement Rules (Case & Work Order)
- Sharing Rules
- Restriction Rules
- Validation Rules
Retiring features
Salesforce announced in 2021 that it is retiring the Workflow Rules and Process Builder features in favour of Flow. This change is part of Salesforce’s effort to streamline and modernize its platform.
For those unfamiliar with Workflow and Process Builder, they are tools that allow users to automate various processes within Salesforce. Workflow Rules is a set of rules that can automatically trigger specific actions based on certain criteria, such as sending an email or updating a field. On the other hand, Process Builder is a visual tool for building automated processes and workflows, allowing users to create complex automation without needing code.
It’s worth noting that Workflow Rules and Process Builder will not disappear overnight – Salesforce has stated that they will continue supporting these features for the foreseeable future. However, it is strongly recommended that users begin transitioning to Flow as soon as possible, as support for Workflow Rules and Process Builder will eventually be phased out. The first signs are already here, as you can no longer create new Workflow Rules. And yes, not being able to create new automation with Process Builder is next!
So let us take these out of the equation, shall we?
Why? Because they are known for some quirky behaviour:
- The order of execution takes a turn for the worse in complexity
- Custom validation rules, flows, duplicate rules, processes, and escalation rules aren’t run again with Workflow field updates.
- Workflow Rules executes before update triggers and after update triggers, regardless of the record operation (insert or update), one more time (and only one more time).
- Recursion (up to 5 more times) in both Workflow Rules and Process Builder
- Workflow Rules and Process Builder can run Flows – that’s a fun one to start debugging
Object specific features
Another consideration to simplify the chain is to look at processes that only run for a limited set of objects. It may have all started with Sales and Service Cloud. But in the meantime, many new products have joined the ecosystem that do not rely on these object types (and the automation that comes with them).
Knowing that we can eliminate:
- Assignment Rules (Lead & Case)
- Escalation Rules (Case)
- Entitlement Rules (Case & Work Order)
Putting it all together
Now that we have taken out all the above from consideration, we end up with the following updated visual:
Why create this diagram?
I am well aware that there is already a clear and documented visual, and it is linked in the article! But this diagram considers all the items I mentioned before (retiring and object-specific), and I wanted a simplified version taking out all of these and seeing what remained.
Modern
When all of the retiring options are taken out, many of the known “quirks” fade into the distance – making our automation more future-proof and robust.
Debugging becomes easier
Another advantage is that debugging the automation becomes a lot easier! There are fewer areas to keep track of, and your logs are cleaner.
You don’t have to catch them all; it is not a game of Pokémon!
"Recursion" begone (almost)!
With the disappearance of recursion (up to 5x with Workflow Rules and Process Builder), we do not have to remember that some automation does not run inside that recursion.
It is still possible to create recursion with the remaining options, but it is much harder to do so – especially if you follow best practices in Apex and Flow.
Getting rid of the Trigger warning
After “cleaning up”, we are only left with a single warning: “The order in which our Apex Triggers are executed.” But luckily, the notice also includes the solution: Using a framework.
Conclusion
We can lower the complexity of our automation “chain” when only modern features are used. And if we are not using Sales or Service Cloud, things become easier to keep track of.
Getting rid of a "chaotic" / fragmented automation landscape is key to predictability & stability of your automations.
Of course, cloud-specific automation will not disappear.
But give it some time, and Workflow Rules and Process Builder will take their leave from the official diagram.
And that will bring the above diagram closer to being obsolete! But until then, feel free to use the visual and make a copy to keep it up to date for yourself!
For that reason, I have shared the link to the original Lucid file (look at the image) - so others can take charge and make updates where necessary.
