Spring 20 brings a cool new feature for declarative developers. We can now build before save update flows that are triggered by record creation or updates. This flow type is 10x faster than a record change executed by process builder.

Changes will be made to the new or existing record (not any related records) before the record is saved to the database, rather than after record creation or update as done with process builder.

You cannot currently use the IsNew() syntax in flow to determine whether a record is new. Rather, check that the {!$Record.Id} is null. Use $Record, a global variable for the record that triggered the flow, when you need to reference the record’s fields. In a before save update flow, the new record has not been committed to the database and therefore does not yet have an Id.

In a Before Save Update Flow, you have a smaller subset of flow elements available for use: Assignment, Decision, Loop and Get Records. You may notice that there is no Update Records flow element. Don’t worry. Use the Assignment flow element to assign values to the new or existing record upon save.

With the introduction of this new feature, it has now changed to the Order of Execution.

The Before Save Updates flow occurs after the process to load the new record field values, overriding the old values and system validations and before the execution of all before apex triggers.

It is important to note that record value changes from a before save update flow can impact whether the record would be touched in your before and after triggers as flows historically are executed previously as Step 13 in the execution order with processes.

Here are a few lessons learned from implementing this use case:

• Learn how to create a before save update flow that triggers on record creation or updates.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes variables, the purpose of a flow, what each flow element does, etc.

Business Use Case:  Addison Dogster is the system administrator at Universal Containers. Mary Markle is the Director of Sales. She would like to enforce a standard naming convention for opportunities to append the account name to the opportunity name provided by the user.

Solution: There are many ways to solution requirements in Salesforce. While Addison can build a process that runs on opportunity record creation or update to set the naming convention, this #AwesomeAdmin keeps up with the latest release features and decided to solution this with the before save update flow feature as it update records 10x faster than a process. (Note: A separate process will need to be created on the Account object on Account Name change to update the name on related opportunities to set the opportunity naming convention. That will not be covered in this blog post.)

The outcome looks like this:

This flow does the following: (1) runs when an opportunity record is created or updated, (2) looks up the opportunity’s account name, (3) determine whether the record is new or existing and there is an associated account and if so then (3a) if new, update the opportunity name to the “<Account Name> Deal – <Creation Date>” (3b) if existing, update the opportunity name to the “<Account Name> Deal – <Creation Date>” and add “The opp name has been updated <today’s date in mm/dd/yyyy format>” to the description field.

Steps: 

1. Let’s create the flow. For those using Salesforce Classic, flow can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows.

A. Let’s create our flow resources.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

Let’s create a text variable called “varAccountName” that will store the Account Name.

Create a formula resource called “DescriptionFormula” that has a text data type, which will update the description field with “The opp name has been updated month/day/year.”

Formula: ” The opp name has been updated ” &
TEXT( MONTH( today() ) ) & “/” & TEXT( DAY( today() ) ) & “/” & TEXT( YEAR( today() ) ) & “. “

Create a formula resource called “OppNamingConventionFormula”, that has a text data type, which will update the opportunity name field with “<Account Name> Deal – <month/day/year>”, limited to 120 character (max length for the opportunity name field).

Formula: LEFT(({!varAccountName} & ” Deal – ” &
TEXT( MONTH( {!$Flow.CurrentDate} )) & “/” & TEXT( DAY( {!$Flow.CurrentDate} ) ) & “/” & TEXT( YEAR( {!$Flow.CurrentDate} ))),120)

B. First, edit the Start flow element by double-clicking on it.

Under the “What Launches the Flow,” select the “New or updated records – flow makes fast field updates.” This is what tells this to run on a record create or update.

Under the “When to Start the Flow,” select “A record is created or updated” in this use case as we want to cover both scenarios.

Lastly, provide the Object. In this use case, the object is “Opportunity.”

C. Next, we will query the Account object to get the Account Name that we will use in the Opportunity Naming Convention. The opportunity record only has access to the AccountId. So, we need to use the Get Records flow element.

Object: Account

Filter the Account Records by Id Equals {!Record.AccountId} (This is search on the account associated to the opportunity.

For the “How to Store the Data” option, I chose to use “Choose fields and assign variables (advanced)” because I only care about one field but you can use the first two options as well. It’s just a preference thing in this case.

Select Variables to Store Account Fields: Name to {!varAccountName}

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

D. We will a Decision flow element to determine what path the flow should take for a new or existing record that is associated to an account.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

For the “New” outcome, we need to check that the record is new by checking that the Id is null (aka has not been set) and there is an account associated to the opportunity. Set the conditions to the following:

{!Record.Id} Is Null {!GlobalConstant.True}

{!Record.AccountId} Is Null {!GlobalConstant.False} (This is a double negative. Which means, there is an associated account.)

For the “Existing” outcome, we need to check that the record is existing by checking that the Id is not null (aka has an Id) and there is an account associated to the opportunity. Set the conditions to the following:

{!Record.Id} Is Null {!GlobalConstant.False} (This is a double negative. Which means, there is an Id.)

{!Record.AccountId} Is Null {!GlobalConstant.False} (This is a double negative. Which means, there is an associated account.)

View image full screen

E. For a new record, we need an Assignment flow element to assign a value to the field that we will update in this flow. We want to set the opportunity name to our standard opportunity naming convention: “<Account Name> Deal – <Creation Date>”.

Set the variable values to: {!Record.Name} Equals {!OppNamingConventionFormula}.

F. For an existing record, we need another Assignment flow element to assign a value to the field that we will update in this flow. Like for the new record, we want to set the opportunity name to our standard opportunity naming convention: “<Account Name> Deal – <Creation Date>” but we also want to add “The opp name has been updated <today’s date in mm/dd/yyyy format>” to the opportunity’s description field.

Set the variable values to:

{!Record.Name} Equals {!OppNamingConventionFormula}.

{!Record.Description} Add {!DescriptionFormula}

View Image Full Screen

G. Set your flow starting point. And connect the flow elements and outcome connectors to match the below…

H. Save/Save As and provide the following properties.

Best practice tip: Provide a description so you and other/future admins know what this flow is used for.

I. Click the “Activate” button.

Now, before you deploy the changes to Production, don’t forget to test your configuration changes.

1. Create an opportunity associated to an account. Verify that the opp name is updated to “<Account Name> Deal – <Creation Date>”.
2. Update the account associated to the opportunity. Verify that the opp name is updated to “<Account Name> Deal – <Creation Date>,” reflecting the new account name and the description field was updated to include “The opp name has been updated <today’s date in mm/dd/yyyy format>.”
3. Don’t forget to do the negative testing. Create an opportunity that is not associated to an account. Verify the naming convention is not changed from your original opportunity name.
4. Make an update to the opportunity, keeping the account field blank. Verify the naming convention is not changed from your original opportunity name and the description field was not updated.

Deployment Notes/Tips:

• Flow can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
• You will find flow in a change set under the Flow Definition component type.
• Activate the flow post deployment as flows deploy inactive in Production, unless you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must launch at least 75% of the total number of active processes and active autolaunched flows in your org.