When building in Salesforce, it is essential to keep in mind the order of execution of the different components that make up a Salesforce build. These components consist of almost anything you can think of, from Point-and-Click to well-written code. In the image below, you can see the order of operations that Salesforce follows when taking such components into account.
An example of a basic order of operations can be: first looking at validation rules, then looking at before triggers, followed by after triggers, and then lastly workflow rules and process builders. While this is a simplistic look at the system, it is a good flow to use as a guide for maneuvering around the perils that can exist when building in Salesforce but not taking the order of operations into account.
"An example of a basic order of operations can be: first looking at validation rules, then looking at before triggers, followed by after triggers, and then lastly workflow rules and process builders."
First up in possible errors is the ever so hated, FIELD_CUSTOM_VALIDATION_EXCEPTION error. This is most commonly seen on workflow rules, process builders, and even triggers. The cause of this error is always the same: whoever built the logic forgot to check if there were validation rules in place, either on the object at hand or on a related object that is impacted by the change attempted to be made.
The creator of the Process Builder forgets entirely to check the validation rules when building and, therefore, does not populate nor checks to see if that checkbox is marked correctly. Hence, on the first round of testing they do, the above error pops up. They must now see what validation is in place that is preventing the action from occurring.
Of course, this example is highly simplistic, but imagine a scenario with 50 validation rules and 10 process builders and three triggers. If you didn’t remember to check these things, you could end up with a whole host of issues on your hand. The same also goes for the inverse. Don’t forget to update processes that fire when validation rules are added up or updated.
Alright, onto another example. This one is more common in the coding world of Salesforce but does play its hand heavily on the Point-and-Click side too (although more commonly forgotten): the dreaded reliance on data from another flow. There is an order of operations to keep in mind even amongst the process you can have in place. There is a reason why Salesforce is pushing folks away from workflow rules into process builders, and why they established the process of one trigger per object. They both boil down to not knowing what will fire first. In the context of triggers and process builders, if you have too many that act at the same time on the same object, you lose control over which should fire first.
Again, let’s go with a simple example. I created a Process Builder that fires on the Opportunity and updates the Stage to 'Commit' when a checkbox called Commit is marked 'True'. This Process Builder fires on both create and edit with no conditions. At the same time, I have a workflow rule that sets the Checkbox to 'Commit' anytime the user changes the Forecast stage. This workflow rule also fires on anytime an Opportunity is created or edited. While most of the time you may see this work, you are relying on two processes that can fire at the same time; meaning, the action of the Process Builder could be missed if it tries to fire at the same time as the workflow rule.
It is crucial to handle these types of processes across the board (flow, triggers, workflow rules, and process builders) with care. Many of them can fire in orders you do not expect and thereby leading to unexpected results. You can also end up with an infinite loop, depending on the criteria in place as they may keep causing new rules to fire, that then lead to older rules firing, and the process repeating. Ending up in this scenario can result in CPU overages or locked out records — neither of which are fun or easy to diagnose.
The recommendation here is to ensure your processes are singular in nature per object and per event type. Make sure to follow the One Trigger Per Object methodology as well as the One Process Builder Per Object methodology to help ensure you do not run into these issues. Today, Salesforce doesn’t display anything to the user for triggers, but if you try to create a new Process Builder on an object that already has one, you will be warned.
Honestly, this list of example could go on for days. All you need to do is to look at the developer forums on Stack Exchange for Salesforce and you will see errors left and right. While not all of them have to do with the Order of Execution, quite a lot of them can be boiled down to something related to it.
The Order of Execution is something to always keep in mind, whether you are creating Assignment Rules or Auto-Response rules. Monitoring the timing and the impacts a change can make will help keep your org healthy over time. I write this coming from a place of having forgotten to keep this in mind myself and spending hours trying to resolve incorrect emails going out (workflow rules vs. case settings vs. assignment rules) or trying to understand a flow error.
You can save and print the Save Order of Execution Diagram from the link below.
What Certification are you studying for now?
Focus on Force currently provides practice exams and study guides for sixteen certifications
The Apex developer guide (https://developer.salesforce.com/docs/atlas.en-us.234.0.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) has escalation rules before processes and flows. What is the correct order?
Hi Jonathan, thanks for the enquiry. That is right. We’ll have the image updated accordingly.