Salesforce has a bunch of rules that can be defined on objects and fields. For example you can define validation rules, workflow rules, proess builder, flows, assignment rules, escalation rules, auto-response rules, triggers etc.
Whether you are an adminsitrator, consultant, developer or architect – it is important for you to understand the order in which these rules and triggers are executed.
The following picture depicts the order of execution visually. (For finer details, please click here).
(Click on the image to view it in full screen. You may also want to take a printout and keep it in front of you when desiging your solution)
(By the way if you are preparing for Platform Developer Certification, there are a couple of questions on the order of execution)
- System Validation rule (required field, field format & length)
- Before Triggers are executed
- Custom Validation rules are checked
- Duplicate Rules are executed
- Record is saved to database but not Committed
- After Triggers are executed
- Assignment Rules are executed
- Auto-Response Rules are executed
- Workflow Rules are executed
- Before and after triggers are executed one more time if the workflow rule updates a field
- Execute Processes (Builder) & Flows
- Escalation Rules are executed
- Execute Entilement Rules
- Parent Rollup Summary Formula or Cross Object Formula fields are updated in the respective objects. (These parent records also goes through the entire execution order)
- Criteria Based Sharing rules are evaluated
- Commit DML operations to database
- Any Post-Commit Logic is executed (like sending an email)
And here is my crazy way of remembering this order (based on techniques suggested by memory experts 🙂 )
“Validate system before someone pulls the trigger as no manual validation will allowed for duplicates check after the trigger is pulled. To assign this work to someone, do it through auto response because the workflow process is built on a logical flow. If you don’t want to escalate and risk your entitlement avoid rolling these things up to your parent. The criteria for you is to commit to this and confirm through email notification.”
(If you can come up with a better story to help remember the sequence, I would love to replace mine with yours. Please suggest your story in comments below.)
Keep this sequence in mind while designing your solution and your app will behave properly.
Now, at times things will not work as you expect it to. Your system may behave like a drunk (or at least you would think so). In such cases ‘Debug Logs’ feature in Salesforce will come to your rescue.
Consider this scenario. Say there is a Lead assignment rule defined in Salesforce that assigns all “Hot” leads to the user “Nick Admas”. Then there is a workflow rule with field update action defined that sets the Industry picklist field of Lead to “Technology” if City is San Francisco. Next, there is a Process Builder with criteria if Lead Status is “Site Visit’ then a Site Visit record should be created automatically mapping values from Lead.
If you are using a criss-cross of different features in Salesforce and running into issues where the system is not behaving the way you expect it to, the best way to diagnose and troubleshoot will be to turn the debug on (Setup -> Debug Logs), execute the transaction and then check the debug log. Based on the example given above, here is what you will see in the debug log (click on these images to enlarge).
While these things may sound complex, with a bit of knowledge and a couple of tools in your arsenal, you’ll be good.
(You may also want to check my another blog post that lists 20 different monitoring and auditing tools available in Salesforce. Please click here if you want to take a look at that )
This blog was first published in August 2014. It was susequently updated in August 2019 to include duplicate rules, process builders and flows.