We keep hearing about the performance of “Fast Field Updates” but how fast is “fast” when it comes to Flows?
Today, we’re going to go through some processing of simple Flows and check their speed. Better yet, we can compare the speed using similar operations on an After Save update.
First, let’s determine when we should use a Before Save vs an After Save.
Before Save Flows have built in guard rails to ensure that we are not including elements that will automatically fail if the operation cannot handle it. For example, Before Save Flows cannot update related records or otherwise.
So if we have a use case for updating the Lead record whenever a Phone Call Task is created, the Flow options will not even give us a chance to update a related record. Notice that all of the options are grayed out except for “Use the task record that triggered the flow.”
![](https://cdn.prod.website-files.com/6283ab3d081a583e11a06914/667dbb02ebc73ae7118a3df2_AD_4nXcweSEpQk6RtzGXASUnvo2btv9UbWTAfdyc_wK5lyJeDIFaWSFqxo10yoz1QMJkMh_LmNzp_8xMSfEu7_vhIRceOYRUR0S70YflLukdu2H4qEaYMjm9KtG_PTO6UBTz45aMIvgvIX2S86TJtbIzkyViD2ua.png)
The best rule of thumb when deciding if a Fast Field Update is best suited is to ask: “Am I updating a field on the same record that is triggering the action?” If the answer is Yes, then Fast Field Update is your solution.
A simple, common use case is to update a Date/Time stamp field when something is updated, such as moving to a new Stage or Lead Status.
Now, let’s define our test use case.
Let’s say we have an “Unqualified” Status value on the Lead record that needs to be date/time stamped for easier record management. Additionally, we need to update a simple checkbox that can be utilized in summary reports.
And that’s it! This is a good example of a Fast Field Update. We can further expand this by adding decision elements, making it dynamic for those Oopsie moments when a Lead is accidentally moved to Unqualified.
Before Save operations can utilize a bevy of elements within the “Logic” folder of actions.
![](https://cdn.prod.website-files.com/6283ab3d081a583e11a06914/667dbb02ebc73ae7118a3ded_AD_4nXcXkWLx2LY2ISqcAJIrwfIglvPVp0FIIWjWPAurRhwbU4KnoDVPQqdeT4Zyy4qf7RvnvBTMxZY8wpfTk03ZESxUnfLKqcAcD1ryJZiMNJ4NmNoJOnKlz7XH9a81zKWRAj9b5VTHvhx1lIbgr5MfvG1iiPxX.png)
By adjusting our structure we can incorporate this change to reflect either scenario.
Time Example
In our example, we have 2 Flows, one on Before Save and one on After Save - they are doing the exact same things, updating Unqualified = TRUE and Unqualified Date/Time = NOW()
Before Save
![](https://cdn.prod.website-files.com/6283ab3d081a583e11a06914/667dbb02e97a0d486de9e713_AD_4nXeo6es8n4fYuLsp2JcGpuOrIxXkPn8Iqr9Dd5Jk75xF9p9V0xABGjJmPo9OsVmckm11-tV5RfekFhB2AU8WeL1MPRHjvlXjSxo8pnUXP9OKlzexKy65yqIoWaBwuFvs-TU5C9q4VPHR8gTO-l5xYh84h0_y.png)
After Save
![](https://cdn.prod.website-files.com/6283ab3d081a583e11a06914/667dbb0267d63191e44506c3_AD_4nXfypJ01aOuuVgI9v6apyx9hqf_nL1FxtezqX8lDeS5vcifJm6xIcFY5j9oYzZdjcvflQhDk8JqC67PDdcyfHWLpB1_PQBB1wO-mx-xF3Ld1eU5LJo4mAuR1w2NfLp8dg7_IEh8VTCkkiOLa1mM6IzX6IEs.png)
In our Before Save operation, we have the Flow running for a total of 0.43 seconds!
In our After Save operation, we have the Flow running for a total of 0.55 seconds!
Wow! Amazing time efficiency saving by using a Before Save rather than After Save!
….
Obviously I’m being a little tongue-in-cheek here but the point is made, it’s faster. Especially when you are taking into consideration the volume of processes currently running in this org (newly created Dev Edition for the purposes of this post) vs a 100 user org with multiple integrations, processes, apex and teams all independently vying for resources to process actions in your Salesforce instance.
One other thing you’ll notice in how this is set up is that I’m using an Assignment element instead of an update element. Let me explain.
![](https://cdn.prod.website-files.com/6283ab3d081a583e11a06914/667dbb0204c1e295a0341ad5_AD_4nXe2HWu3RCpcoB1Pe01r39LSNOGbJJ01BUd6GzDNBqRHujSjha-ximItK5XI_BN7ttHIzBAVYCOkUdhbSufqkwdEG4hR1sLgzusxctEG15WK9daETv5tmms5vnqNeyYUll6eNVztI-VFsmMXA7mNfGeooPdQ.png)
When using an Assignment element, we are simply adding a value to a variable within the operation; while the latter is definitively updating the record.
With a Before Save operation, the record has not been committed to the database yet so it is in this limbo mode prior to that final stamping to the database. While in this limbo state, we can assign values as we need to similarly to when we bulkify record updates in an After Save operation using a single DML statement.
Well great, Dave, you told me all about this stuff here but what am I supposed to come away with after reading this blog post? The biggest take away here is to give you the perspective of when and why you would look to use a Before Save operation rather than an After Save operation.
There are plenty of additional scenarios as well to consider but we don’t have time for that now. However, at LeedsSource, we pride ourselves on looking at the entire picture and solving for a myriad of potential problems.
Understanding all of the different tools within the Salesforce ecosystem and when to use each of them is something we really love helping our clients with. Whether it’s a simple Before Save Flow to update Unqualified values or it’s a full scale migration / implementation of Salesforce, we can help!
If you’d like to learn more about what we do and who we are, take a look at our Who We Are page. Follow us on LinkedIn to stay up to date with all our latest releases, blog posts, and videos. Also, be sure to check out our Youtube video discussing Salesforce triggered flows!
-Written by Dave Arena, Senior Consultant