Salesforce recently launched a new feature in Spring 20 release i.e. before-save updates using lightning flows. We can simply define these before-save update in flows as the flows that update a record before it's committed to the database. Let's call them "Before-Save Update Flows".
So, we can say that the before-save update flows can be fired when a record is created or when a record is updated or both - when a record is created/updated. Because in these 3 conditions, we can update a record before it's committed to the database.
Now, the question arieses:-
We can perform the same operation using a Process Builder.
Why should we use "Before-Save Update Flows" ?
- Opportunity Rank is Bronze if Amount < 10,000
- Opportunity Rank is Silver if 10,000 <= Amount < 50,000
- Opportunity Rank is Gold if 50,000 <= Amount < 100,000
- Opportunity Rank is Platinum if Amount >= 100,000
It's time to create a flow now:-
Amount < 10,000 |
10,000 <= Amount < 50,000 |
50,000 <= Amount < 100,000 |
Amount >= 100,000 |
Update Opportunity Rank to Bronze |
Update Opportunity Rank to Silver |
Update Opportunity Rank to Gold |
Update Opportunity Rank to Platinum |
1. Creating a new process builder which will fire on record change.
2. Process builder is created on Opportunity Object and will fire when a record is created or edited.
4. For each condition there is a related action which will update the Opportunity Rank field of the Opportunity Record that started this process. As, you can see below, for the above condition, I have updated my Opportunity Rank field to Silver.
5. The final process builder will look as shown below. Don't forget to Activate the process builder to use it.
Now comes the fun part. As we know that we have a before-update flow and a process builder doing the same thing. There is no workflow rule, assignment rule or any other thing on my opportunity object in my org, but I do have a Validation Rule and an After Insert Trigger ( Which consists of a SOQL query) on the opportunity object to test the performance.
First I activated the flow and deactivated the process builder and created a new opportunity and then I deactivated the flow and activated the process buider and created a new opportunity again. I got the two logs as shown below:-
Can you see the difference in the processing time above ?
Now, let's discuss why did this happen. I checked the logs and got the below scenarios:-
1. Before-Save Update Flow:- The events occured in the following order:-
- Before-Save Update Flow executed and updated the rank field on opportunity.
- Validation rule executed.
- Opportunity Trigger executed and performed a query (SOQL Count - 1) which is inside the trigger written on after insert
In the above case the number of SOQL queries was 1 as my trigger executed once and rest everything was 0 as you can see below:-
2. Process Builder:- The events occured in the following order:-
- Validation rule executed.
- Opportunity Trigger executed and performed a query (SOQL Count - 1) which is written on after insert
- Process Builder executed. This process builder queried the record which was saved in the database (SOQL Count - 2) and updated the rank field and saved the record again (DML-1).
- As the operation was performed on the same record, validation rule was executed again.
- Similarly, Opportunity Trigger executed again (SOQL Count - 3).
The only strange thing that happened in my case was that the Custom Validation Rules were also fired again. However, it's written in the documentation that they are not run again. I'll research more on that and update you accordingly. But after all this research, we came to a conclusion that:-
"Before-Save Update Flows are faster & take less processing time than Process Builders"
That's all for this post. If you liked it make sure to share it in your network and let me know your feedback in the comments down below.Happy Trailblazing..!!
Very nice keep it up bro..
ReplyDeleteThank you brother. Make sure to share it in your network too :-)
DeleteThis is an awesome breakdown. This was clear and helped my understanding of speed between two automation solutions.
ReplyDeleteGlad to know that you liked it :-) Keep Learning..!!
Delete