Before Save Update Flows v/s Process Builder | Salesforce #Spring20 Release

Hello Trailblazers,

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" ?

Well, Salesforce Documentation says that the before-save update flows are 10 times faster as compared to the process builder.

To answer this question, we're going to take a simple use case and we'll create a before-save update flow, as well as a process builder and see the difference. So, let's begin 😎

I am taking a sample use case in which I have created a new picklist field on my opportunity named as :- Opportunity Rank (Opportunity_Rank__c) which can have 4 values:- Bronze, Silver, Gold and Platinum. I want the opportunity rank field to be automatically updated when a record is saved based on the following criterias:-

1. Opportunity Rank is Bronze if Amount < 10,000
2. Opportunity Rank is Silver if 10,000 <= Amount < 50,000
3. Opportunity Rank is Gold if 50,000 <= Amount < 100,000
4. Opportunity Rank is Platinum if Amount >= 100,000

It's time to create a flow now:-

1. To set the flow to fire automatically, when a record is saved double click on the start icon.

2. You'll see a dialog box as shown below. Set the What Launches the Flow radio button to - New or updated records - flow makes fast field updates and Choose When to Launch the Flow radio button to - A record is created or updated. Also, set the object to Opportunity as we're dealing with opportunity here.

3. Click on Done. Next, we created a Decision box where we stored our conditions as shown below. You can click on the (plus) + Button to the right of OUTCOME ORDER heading in the left panel to add more outcomes as I have added below:-

Amount < 10,000

10,000 <= Amount < 50,000

50,000 <= Amount < 100,000

Amount >= 100,000

Now, our outcomes are ready according to the condition so, it's time to update our record. Salesforce provides us a $Record global variable in this type of flow which is actually the record inserted/updated. So, all we need to do is to update the Opportunity Rank field in that $Record variable and salesforce will handle the rest.

In order to update the field, I have created 4 assignments for my 4 conditions which are given below:-

Update Opportunity Rank to Bronze

Update Opportunity Rank to Silver

Update Opportunity Rank to Gold

Update Opportunity Rank to Platinum

Finally, I connected the appropriate outcomes to their correct decisions, so that the final flow will look like as shown below:-

I activated this flow and tested it and got the correct result as shown below:-

Now  it's time to create a process builder. I am not going to tell the step by step instructions for the same, but I am pasting the necessary screenshots below so that you can make it easily:-

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.

3. There are different criterias in process builder like the one shown below which is checking :- 10,000 <= Amount < 50,000

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).

In this case, we had 3 SOQL queries and 1 DML statement executed as you can see below:-

If you check the order of execution in the Salesforce Docs here. 

You'll get to know that this happened because the Before-Save Update Flow execute after the system validations and before everything else. Therefore, all the changes are executed even before the record is saved in the database.

However, in case of process builder, it is executed like a workflow rule and you can see that at point 7 the record is saved but not committed and the workflow rule execute after that at point 11. And in our case the point 12 was also valid i.e. our process builder updated the same record therefore triggers and validations were fired again. Therefore, the process builder queried the record again as it was saved before (+1 SOQL) and saved the record again in the database (+1 DML) and the trigger (+1 SOQL) and validation rule was executed again as written in point 12.

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..!!