On a recent article, we discussed what to do if your PB and Flows were giving you Governor Limit-induced headaches. Fortunately (especially for all of you who prefer not to delve into apex), in Spring 20 Salesforce released another feature to help us tackle this: Before-Save Updates.
Before-Save Updates work very similar to what a “before trigger” does and are another tool we now have to solve these insidious problems. If you didn’t read the previous articles, here is a refresher on why “before triggers” are really good for consolidating multiple PB into one place.
The advantage of “before triggers” (instead of “after triggers”) is that the records are updated before they are committed to the DB, so changes there will not cause triggers to fire twice
Just like when you update a record in an ‘“after trigger” context, regular Flow and Process Builders that make updates to records cause the object’s trigger to re-fire. By migrating your logic into this new kind of Flow, you save yourself all the extra processing and that valuable CPU time that comes associated with it.
How do I fix this?
To create a Before-Save flow, start by creating an Autolaunched Flow the normal way, and then choose the following options on the “Start” node
As you can see, this looks really similar to a trigger, you even have to pick your object!
When you finish, the first thing you will notice is that you have a severely reduced list of choices. This is because in this context there is only so much Salesforce lets you do. However, you will find that you can do most of the basic tasks that you can do in PB (like decisions and assignments) with the addition that you can also loop on records and even query from other objects. That’s really cool.
Now, most people’s instinct is to use the “Get Records” action to get the records… but that is not a good idea. Why? Well, your newly created records don’t have an Id at this point… in fact, part of the advantage of the Before-Save context is that the records have not been committed to the Database… so there is nothing to query!
Instead, you don’t even have to iterate at all. The flow will run per each record in the context, and you can use the
$Record system variable to evaluate the record in question. You can use this variable both in assignments and in decisions, making your life super simple!
In summary, if you’re having Timeout problems, or even if you’re considering optimizing the way your Flows and Process Builders work, you now have another tool to ensure your org is in tip-top shape and scales properly as you grow.
theCodery understands the challenges in modern tech stacks. We have developed a personalized approach for each Salesforce Cloud implementation while leveraging our deep been-there-done-that and best-practice expertise to ensure you get the most value from your Salesforce deployment. We take an agile approach with all development, optimization, and integration projects. Whether you are trying to broaden your engineering and development capabilities, reduce technical debt, integrate tools you are unfamiliar with, or create new applications, theCodery has a proven track record of solving problems and streamlining complexity.
If you have any questions for theCodery about our team, our process, or the clients, please reach out to us at: https://www.thecodery.io/contact-thecodery
theCodery: Accelerate your time-to-value on Salesforce with a trusted partner that delivers scalable architectures that are tailored to delight your customers.