Salesforce has a bunch of rules that can be defined on objects and fields. For example, you can define validation rules, workflow rules, process builder, flows, assignment rules, escalation rules, auto-response rules, triggers etc.
Whether you are an administrator, 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 refer to the Apex Developer Guide URL mentioned under ‘References & Useful URLs‘ section below).
Thanx, ashish
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.
Let’s say that we have configured the following on Lead object
- There is a validation rule on the lead object that states that if the lead rating is hot, the email cannot be blank
- Then we have configured duplicate rules in Salesforce to ensure that the lead being created does not already exist
- Then 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 combination 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 (hover on these images to enlarge).
Keep this sequence in mind while designing your solution and your app will behave properly.
(By the way if you are preparing for Platform Developer Certification, there are a couple of questions on the order of execution)
References & Useful URLs
- Triggers and Order of Execution – Apex Developer Guide (15 mins) – https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm
- Blog Post – Monitoring & Auditing Tools in Salesforce
Hi All,
Anyone can please help me that above steps are correct but are they mentioned in Salesforce release notes?.
I can check the given steps on one of the knowledge article of salesforce but didn’t find anything in release notes.
H Vishal, the order of execution is not mentioned in the release notes. You can find it in Apex Developer Guide -> Triggers and Order of Execution at URL https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm
Thanks its helpful and good explanation.
My pleasure Nezam 🙂
This order appears to no longer be valid. Spring 20 introduced Before Save Update Flows that run prior to the before triggers. This would also mean step 10 would need to be updated in the process as flows are running at a different time.
Hi Dennis, thanks for your feedback. The order has now been updated based on the Winter ’21 release of Salesforce.
That is a great way to memorize the sequence. thank you Agarwal!
Thanks, Tulasi.
Thanks Tulasi
what about process builder
Duplicate rules?
Just Awesome 🙂
nice
very well explaned…..For KT
after field update coz of WR, only BT and AT will fire but no SV, CV, AR, ARR, and WR. Correct ?
Awesome
Very well explained
It is Well Explained
Was wondering where cross object formula’s come into play and this was an enormous help ! Awesome job.
Thanks Morvana, Glad that it helped
If Before trigger fails then, what happen to rest of execution.Whether it will stop other execution or it will execute the remaining process?
good one
It Helps me alottttt….
Thanx, ashish
Thanks a lot. Its very useful
You left out several important points – like when the records(s) are soft written to the database and then eventually committed to the DB.
It’s critical to understand that the before triggers are b/4 the write to the database and ther after triggers are after the write to the database but before the committ.
Thanks. Good to remember this one.
very helpful post. Is this true though – If a validation rule throws an error (i.e. the Validation Rule is working as designed), the BeforeUpdate code will get thrown away (e.g. if our BeforeUpdate code is supposed to create new Opportunity when changing Stage).
This helped me a lot. 🙂
Glad to know that it was helpful Eugene !
Good article, clear explanation
That is very well explained
Thanks Ashish !