Salesforce Flow: Before-Save Trigger
Record Triggered Flows
A relatively new feature of Salesforce Flow is the ability to to run record-triggered flows (introduced in Summer '20 Release). If you are familiar with Process Builder, you know how it works. When a record is created or updated, a process is triggered. So, why would you use Flow if Process Builder works the same?First of all, Salesforce Flow isn’t bound by the limitations of relations between records. In Process Builder you can only update another record if there is a direct connection between that record and the one that started the automation. In Flow, you can use field values as criteria for which record should take part in the process. It can be a completely different object, unrelated to your starting record, as long as it fits the criteria.The other reason to use Salesforce Flow for record-triggered automation is that you can run flow before a record is saved. If you’ve never worked with a “before” trigger, it might not sound like a big deal. This feature is very useful when you want to validate or change a field by looking at another record. In other words, the same functionality of Salesforce Flow as mentioned before - the ability to use criteria to check other records - may be leveraged to update a record before it is saved to a database. And, it’s important to note, this kind of automation is 10x faster than a record change executed by process builder.Let’s see how it works.
Prevent Field Update with a Before Save Trigger
Let’s create a scenario where we need to look up a different record before an opportunity is updated.For example, a sales rep is responsible for updating the opportunity stage. The company standard says that if there are unsolved cases related to the same account, the opportunity’s stage cannot be changed to Closed Won or Lost.To create this automation, we will need a combination of a validation rule (on the opportunity object) and a flow that runs before the opportunity’s stage is updated.First of all, let’s create a new custom field on opportunity.
Label: Open Cases Validation
This field indicates whether any of the cases related to the same account are open. It should only be visible to Administrators.Now, let’s create a validation rule that looks at that field and prevents the user from updating the stage to Closed Won/Lost when it’s checked.Our formula needs to check if the StageName is either Closed Won or Closed Lost, and at the same time look for the TRUE value in the newly created checkbox.The formula is going to be as follows:AND(OR(ISPICKVAL(StageName, "Closed Won"),ISPICKVAL(StageName, "Closed Lost")),Open_Cases_Validation__c = TRUE)
You can check yourself if this validation rule is working for you. If that’s the case, let’s go to the next step - building a flow.
Create a new record-triggered flow
Firstly, we need to configure the Start element. We want the flow to trigger when a record is updated or created. And the key thing to do here is to tick the checkbox where it says Run the Flow: Before the record is saved.
This way, we’re telling Salesforce to perform all the actions of our flow before the record is actually saved to the database.Next, we configure which object should trigger this flow, and when. In this case, we want this automated process to run when a user changes the opportunity stage to Closed Won or Lost.
Now, the purpose of this flow is to automatically select the custom checkbox we’ve created before when there are open cases. To do so, we need to find those related cases.Drag and drop the only Data element available in the menu - Get Elements. Just like in any other flow, we need to use filter criteria to find the right record.We are looking for a case with the same parent account as our opportunity. The values from the record that triggered the flow are available as a Global Constant.We also need to make sure that a case is open.We don’t have to find all cases that fit our criteria. Even if one is found, this means we can’t let the opportunity stage change.To prevent the flow from failing, be sure to manually select variables to store case fields, and tick the checkbox that says “When no records are returned, set specified variables to null”.
Now, let’s add the decision element to check if the variable storing the case ID is null. If that’s not the case, it means there is an open case.
As the last step, we’ll configure the decision paths. The first possibility is that our previous query finds an open case. This means we need to check the box on opportunity. To do this kind of operation in a “before” flow, we can’t use the standard Update Records element. That’s what the Assignment element is for.Drag and drop it into the canvas, and use a global constant variable to look for the appropriate field on opportunity. Set its value to True.
Do the same for the other path, but change the value to False.Save it, and activate.Test it out on an account in your org. If you’ve done everything correctly, the validation rule should fire whenever you change the opportunity stage to Closed, while there are open cases related to the same account as the opportunity.
This exercise is just an example of how you can use this type of flow. There are many situations when it could prove useful. As an administrator, or a developer, you should remember that you don’t always have to go for a trigger. Declarative tools have lots of features, and can be a great alternative to custom code.For more articles on Salesforce Flow, check our blog!