Welcome to the first in a series of blogs on automation. If you’re a Salesforce admin, this is for you. We’ll be posting about our thoughts on the latest features that will make your everyday working life a little bit easier.
To launch our first blog, we have our senior consultant, Val, talking about declarative development.
Today I’m going to talk about my latest favourite feature in declarative development – ‘Before Save Record-Triggered Flows‘. It doesn’t exactly trip off the tongue but I think once you’ve made one, you’ll start to realise their potential for making declarative automation much more powerful in your org! Record-triggered flows are relatively new (Summer 20) and I’ve started to see several ways they can be used to great effect.
So what is it?
Let’s start with the alternative. You’ve probably come across triggers, whether you’ve written one or have had a developer make one for you. Triggers can act on a record at key points in the save or delete process. For example, when a new record is created, updated or deleted, it can be updated prior to being saved to the database using a ‘before’ trigger or after being saved to the database with an ‘after’ trigger, depending on how the trigger is written. Triggers are a great way to automate some tasks for your users or make sure data in your org is complete and useful.
Whilst triggers do a great job, they can also be cumbersome for an admin, unless you are also an accomplished developer. They can only be changed in production via deployment, which normally also includes successfully running test classes. In my experience, this can mean rewriting an out-of-date test class just to redeploy a trigger as inactive. Of course a well-thought-out trigger, which utilises custom settings to allow easy deactivation, is very helpful but (sadly) rarely exists, especially in existing client orgs.
What if you don’t have a developer on hand to write a wonderful trigger, complete with admin-thoughtful features?
Enter the record triggered flow (fanfare please!) Bask in the glory of making your own code-free, visual and flexible flow that can update, validate and clean data BEFORE it hits the database!!
How is this better than making updates post-create/update?
Many organisations, which prefer declarative development, use automation such as process builders and workflow which kick in after a record is created or updated. These, in turn may trigger off further automations, building up masses of post-save automation processes. In the absence of a better declarative alternative, it can get difficult to troubleshoot when something goes wrong.
Introducing a well made BEFORE save record-triggered flow, could provide a welcome opportunity to replace a plethora of post-save updates and take some of the burden off post-save automation overall. Additionally, automating BEFORE save can help your org take better advantage of existing features such as custom validation rules, which run after ‘before’ save flows/triggers in the order of execution. By making the change before the record is saved, we also avoid unnecessary database updates and further processing making everything a little quicker.
What’s an example use case?
Let’s look at a simple data quality/validation scenario:
- Galactic Outfitters hold quarterly virtual events for stockist companies to look at new products to sell in their stores.
- Multiple teams of Business Development staff at Galactic Outfitters call lists of stockist contacts to register them for these events.
- Galactic Outfitters uses a custom object ‘Event__c’ and another ‘Attendee__c’ child object, related via a master/detail relationship to record the attendees via a contact lookup.
- A contact can attend multiple events but should not be recorded as an attendee to any one event more than once.
- Occasionally, Business Development staff mistakenly register a contact as an attendee multiple times to the same event. Since events have become more frequent and the Business Development team has increased in size recently, Event Managers have noticed their event attendance reports show incorrect totals and have become frustrated.
For this scenario, we want to validate against a new attendee record being created where one exists already for the same event and contact combination.We can combine a new checkbox field, a before save record-triggered flow and a validation rule on Attendee__c to accomplish this:
New checkbox:
New flow:
We set our Flow to trigger on record creation and set the “Run Flow” option to be before the record is saved. We are working with our Attendee object and set the following conditions – make sure there is a contact and an event for the attendee record (both are not null).
The first set in our flow is a “Get Records” step named “Find Duplicate Attendee”. We find the first record in the Attendee object where Contact = this record’s contact AND Event = this record’s Event.
We then have a Decision node named “Duplicate Detected?” which checks for whether the value returned from “Find Duplicate Attendee” component is not null (i.e. we have an existing record that has matched). If “Yes” we have an assign action “Assign Duplicate Detected” which sets the “Duplicate Detected” field to true, otherwise we end the Flow.
New validation rule:
Try it out:
Et voila!
The user cannot save a new attendee when a matching attendee record already exists. This is because the flow assigns the ‘duplicate detected’ checkbox to true for a matching attendee BEFORE the new record is saved and BEFORE custom validation rules run. The validation rule stops the record from being created and displays the error message to the user. Mission accomplished!
*********
Wise Words
A wise person once said “With great power comes great responsibility“. This is true when we have more power to declaratively automate in Salesforce.
#AwesomeAdmins always think about the bigger picture
It is tempting to automate as much as possible and start adding new process builders and flows for each new requirement that comes along to keep everyone happy.
It is important to always remember the long-standing recommendation from Salesforce that we keep the number of process builders per object to a minimum (ideally 1), where possible. With this in mind, Admins should also develop record-triggered flows along the same lines. In other words – updating & optimising versions of existing process builders or flows instead of creating multiples against a single object.
Utilise decisions, criteria and sub-flows within your single flow/process per object to make sure actions are triggered only when required and at the right time will prevent conflicts, making for a more efficient org and therefore happier users! And – the cardinal rule – ALWAYS test your new process/flow/version in a recent sandbox before activating it in a production environment!
Good luck and most of all, have fun with your new-found power!
