Salesforce Flow is a powerful tool that allows administrators to create automations and guided business processes without having to write code. You can build these powerful automations using a canvas called Flow Builder.
In this chapter we will cover:
We are just scratching the surface of what is possible with this tool. Flows are the future of admin-built automation, and while Salesforce previously had two other automation tools, called Workflows and Process Builder, they will be phased out over the coming years.
Salesforce Flow is an important and powerful tool for any Salesforce administrator, so you can expect this chapter to take some more time to complete. Have patience and take breaks as you work through it.
For this chapter, log in to your development org and follow along with the screenshots provided. When we reach the two example flows in this chapter, it is important that you follow along and build your own flow; this will significantly help familiarize yourself with the process.
Flows are automations that can be built without having to write code. They consist of series of steps, with branching decision logic, where you can define when and what you want a system to do. Below, you can see an example of a flow that we will build later in this chapter:
Figure 16.1: Example of a flow
As you can see from Figure 16.1, this flow contains steps for an input screen, a decision that splits down two pathways, and an action that is performed before completing. We can also see that the flow consists of various elements, such as Decision, Assignment, and Create Records. These are categories from which we pick the steps a flow will follow – see more about this in Understanding Flow Builder elements.
There are several different flow types that can be used for different requirements. Salesforce will ask you to pick a flow type before you begin building a flow, so let’s go through these now.
To begin creating a flow, navigate to Flows on the Setup page, and click New Flow. When you go to create a new flow, you will be prompted to select from several types, as shown in the following screenshot:
Figure 16.2: New Flow screen displaying several flow types
Each type has its own purpose and may fit different business processes or use cases better. In this chapter, we will show an example of a screen flow and a record-triggered flow, which are the two simplest types that have immediate applicability.
This flow type allows you to display screens to an end user to collect or show information. You can incorporate automations and database modifications within this type of flow. This flow type can be placed on Lightning pages, Experience Cloud pages, or launched from a button. An example would be if you want to quickly allow a user to enter a new account and opportunity on one screen from the Lightning utility bar. We will walk through this example later in this chapter.
This flow type is “triggered” when a record changes. This could be on insert, update, or delete and can occur before or after an insertion or update. In contrast to the previous flow type, you cannot display screens to users in a record-triggered flow. An example of when you would use this flow type would be if you wanted to automatically generate a task for an intro call assigned to the account owner whenever a new account is created. We will walk through this example later in this chapter.
This type of flow is what you would use to replace any processes built with Process Builder and can be a substitute for Apex triggers in the right situations.
When you choose to have a record-triggered flow fire on the creation or update of a record, you can optimize the flow for Fast Field Updates or Actions and Related Records. Fast Field Updates is going to make the modification to the record before an insertion or update, whereas Actions and Related Records is going to fire after an insertion or update. Use Fast Field Updates if you are only updating the record that triggered the flow. Use Actions and Related Records if you need to do other actions or update other records in the system.
A schedule-triggered flow runs on a predefined schedule (once, daily, or weekly) and is useful for when you want to run some sort of operation against a set of records on a regular basis.
This is a more advanced flow type that fires based on platform events being published. This flow type is outside the scope of this book and won’t be covered here.
An autolaunched flow can be called by Apex, the REST API, and other flows. It does not have any user-interface elements. This is a more advanced flow type that will not be covered in this book.
Now that we have covered the various flow types to choose from, let’s talk about the elements you will see once you reach the Flow Builder. If you remember from earlier, these elements contain all the steps we will need to build a flow.
After you select your flow type, you will be taken to the Flow Builder canvas where you can add elements by clicking the “+” symbol. Flow elements are all the items you can place within a flow that have different purposes. They represent the “steps” of a flow. As you can see in the following screenshot, they are organized into three main categories:
Figure 16.3: Elements pane on the Flow Builder page
In this section, we will go through each of these categories in turn:
We will also cover flow resources, which are a separate but related concept to elements. First, let’s begin with interaction elements.
Interaction elements are how flows interact with users (via screens) or other automations within Salesforce. These interactions can be broken down into three elements:
The second element type that you can see on the Flow Builder consists of logic elements.
Logic elements are how you define when a flow should do what. Logic element types include:
Next, we will look at the third category of elements visible on the Flow Builder, which consists of data elements.
Data elements are used to make changes to the database. Data element types include:
Now that we have gone through different element types available under the three categories in the Flow Builder, we will turn our attention to flow resources that can be used with these elements.
Flow resources are where you can store and define values to be used within your flow. You can use flow resources within elements. For example, you could use a variable resource in a Create Records element to set a field to a specific value. You can create resources on the Toolbox sidebar of the Flow Canvas or directly within Flow elements. There are a bunch of different resource types:
$
. These can include a representation of the record that fired a record-triggered flow, or things like the current date, or information about the user running the flow.$GlobalConstant.EmptyString
, which represents a blank value, and $GlobalConstant.True
and $GlobalConstant.False
, which represent true
and false
values in a Boolean data type.Flow resources can be of a number of data types including text, record, number, currency, Boolean, date, date/time, picklist, multi-select picklist, and Apex-defined. Record data types represent a record of an object including all of the field values of that record. Apex-defined data types are custom-defined in Apex classes.
Now that we have explored the elements and resources available to us when building a flow, we will look at how we can test a flow before going through two examples of flows in greater depth.
When building a flow you can use the Debug functionality on the Flow Builder to test your flow. This will show you details of how your flow is executed and if any errors are encountered:
Figure 16.4: Debug button on the Flow Builder page
It will be easier to understand this when we use it on a flow that we have built together, so we will see this in action in the Testing the flow sections as we step through some examples.
A quick note on flow testing: you should always build your flows in a sandbox or developer org and test them thoroughly before deploying to production. Flows are an extremely powerful tool that can wreak havoc if used incorrectly and not tested.
In the summer ‘22 release, Salesforce announced Flow Tests (in beta), which are point-and-click tests that you can construct in order to test flows in a similar way to developers testing Apex code. This will likely become the best practice over time.
Now that we have covered the basics on flow types, elements, and resources, let’s build some flows!
For both examples, log in to your developer org.
We will build a screen flow that allows a user to quickly enter a basic account and opportunity from one screen.
Sales users have been complaining that it takes them too many clicks to enter a new account and associated opportunity. They want to be able to search for an existing account or create a new account and opportunity on one screen, regardless of what tab they are on in the Sales app. To do this, we will create a screen flow and make it accessible from the utility bar.
Figure 16.5: Navigating to the New Flow screen from the Setup page
Figure 16.6: Selecting a flow type and creating the flow
We are now in the Flow Builder and ready to create our flow.
Figure 16.7: Adding the Screen interaction to the flow
Account & Opportunity Input Screen
and letting the API name auto-generate. Then, give it a description:
Figure 16.8: Naming and describing the screen interaction
Now let’s drag some components from the left sidebar onto the screen, placing them where we want.
Instructions
, and type up some instructions for your end user:Figure 16.9: Developing the screen by adding a component
Figure 16.10: Adding another component to the screen
AccountLookup
AccountId
(this is the API name of the Account lookup field on the Opportunity object)Existing Account
(this is the label that you want to display on the screen)Opportunity
(this is the API name of the object where the lookup field you want to use is)Figure 16.11: Adding a lookup component and specifying fields
If the user does not find an existing account, we want them to be able to provide the name of the new account.
New Account Name
and let the API Name autofill. Figure 16.12: Configuring the visibility of the lookup component
This means that the New Account Name text input will only show up if the value of that lookup is null
(which means they have not found and selected an existing account).
You could add additional fields to capture additional account information if you so choose, but we will move on to the opportunity information.
We are going to drag the following components into the second column in our section using the names and attributes below.
Opportunity Name
Opportunity_Name
Opportunity Amount
Opportunity_Amount
Close Date
Close_Date
Your screen should now look like the following screenshot:
Figure 16.13: Developing the screen interaction with components
Optionally, you can control whether to display the header or not, as well as some buttons that affect how users navigate the form. For this flow, let’s hide the Header, the Previous button, and the Pause button:
Figure 16.14: Setting the visibility options for the screen
Account & Opportunity Quick Create
and give it a description. Click Save. After each change, you should save your flow as there is no auto-save feature.
Figure 16.15: Naming the flow and its API before saving
There are now two different “paths” we can take. If the user specified an existing account, we should only create an opportunity and associate it with that selected account. If the user defined a new account name, we will create that account, then create the opportunity, and associate it to the just-created account.
To do this, we will use a decision element to determine whether an account needs to be created.
Figure 16.16: Selecting a new element for the flow
New or Existing Account
New_or_Existing_Account
Determines whether the user selected an existing account or wants to create a new one.
On this decision screen, we see what are called “outcomes.” These are the different “paths” that our flow can go down. We will define two outcomes, one for where they selected an existing record in the lookup, and one for where they did not.
Selected Existing Account
Selected_Existing_Account
All Conditions Are Met (AND)
This means that we will go down the Selected Existing Account outcome if they populated the lookup:
Figure 16.17: Configuring a possible outcome of the Decision component
New Account
. This will execute if the first outcome does not evaluate to TRUE
. Then, click Done:
Figure 16.18: Setting the alternative outcome of the Decision element
After you do this, you will see that the flow now branches down two paths: one for where the user selected an existing account, and one for where the user wants to create a new account. (Reminder: click Save on your flow after each step.)
Figure 16.19: Overview of the flow showing two paths created by the Decision element
Figure 16.20: Adding a Data element to one of the Decision pathways
Create New Account
Create_New_Account
Creates a new account
Account
Name
If you are collecting any additional account information you can Add Field and map the field value from the input component you put on the screen.
Figure 16.21: Filling in fields for the Create Record component
This will create an account if the user wants to add a new account.
The next thing we are going to do is assign a value to a variable. We are going to create a variable to represent the account Id. In the path where they selected an existing account, we will set the variable to that selected account. In the path where we created a new account, we are going to set the variable to the account that is being created in the flow.
Variable
varAccountId
Id of account that was found or created.
Text
Leave everything else as is.
Figure 16.22: Creating a variable to represent an account
Now this variable exists, and we can assign values to it.
Figure 16.23: Adding the Assignment component from the Logic element
Assign Existing Account Id
Assign_Existing_Account_Id
assigns the account id of the identified existing account to the variable
varAccountId
Account Lookup > Record Id
Figure 16.24: Filling fields for the Assignment element
So now, if we go down the path of Selected Existing Account, that existing account’s Id will be the value of the varAccountId variable.
But what if we go down the New Account path? In this situation, we want to set varAccountId to be equal to the Id of the account we just created!
Figure 16.25: Editing the component on the other pathway of the Decision element
Figure 16.26: Editing the Create New Account pathway to store the account Id in the varAccountId variable
So now, regardless of whether we are selecting an existing account or creating a new account, the varAccountId variable has the right account Id in it!
Figure 16.27: Adding a new element after the Decision pathways
Create Opportunity
Create_Opportunity
Creates the opportunity
Name
Opportunity_Name
(screen component)Amount
Opportunity_Amount
(screen component)Close Date
Close_Date
(screen component)AccountId
varAccountId
(this is the variable we assigned a value to in the previous steps)StageName
Prospecting
Figure 16.28: Configuring the Create Records component
This element will create our opportunity with the information provided by the user on the screen, as well as the account Id from either the selected account or the new account, and set the stage to Prospecting.
Make sure to Save your flow. And now, we have built our flow! Let’s review what we have done:
Figure 16.29: Overview of the completed flow
Now it is time to test what we have built.
To test your flows, use the built-in debug tool by clicking Debug at the top-right:
Figure 16.30: Clicking Debug on the Flow Builder page
If there are input variables you can define them in the next step; otherwise click Run. When testing your flow, you should try to test every path. So for our example, let’s test the path where we select an existing account first:
Figure 16.31: Testing the Select Existing Account pathway
Figure 16.32: Entering an existing account into the flow
On the right sidebar under Debug Details, you will see all of the elements of the flow that you defined and the results of each step. If there are errors, they will be reflected here.
Figure 16.33: Reviewing the Debug Details pane
Let’s run it again (select Run Again at the top-right). This time create a new account instead:
Figure 16.34: Testing the other pathway of the flow
It should have run again without any issues, but if any were encountered, you will see them reflected in the Debug Details on the right-hand side.
Now that the flow has been tested, we are ready to activate it and distribute it.
Once a flow has been tested you can activate it by clicking Activate at the top-right of the Flow Builder. After you activate the flow, if you want to make changes, you’ll have to click Save As and activate a new version.
Figure 16.35: Activating the flow to use in our apps
Now that the flow is active, we can use it in our Lightning apps. Screen flows can be placed directly on a Lightning page using the Lightning App Builder, or on an Experience Cloud page. For this example, because we want the sales reps to be able to use this screen flow from anywhere in the Sales app we are going to add it to the utility bar:
Figure 16.36: Selecting the Sales app in the App Manager for editing
Figure 16.37: Adding an item to the utility bar for the Sales app
Account & Opportunity Quick Create
480
480
We have now created a flow and distributed it by putting it on the utility bar in the Sales app. Let’s see what it looks like for end users:
Figure 16.39: Selecting the Sales app so we can find the flow
Figure 16.40: Flow appearing at the bottom left of the app screen
We just successfully built a flow that will make it easier for sales reps to quickly enter account and opportunity information from anywhere in the Sales app. You can add additional fields to the flow (on the screen element and create record elements) to collect additional information.
We will build a record-triggered flow to create different tasks for a user based on account type.
Account managers are very busy. They would like to automatically have tasks generated for them when a new account is created. This task should be for them to onboard customers and partners.
Customer accounts should have an onboarding process that includes the user who created the account doing the following actions:
Meanwhile, partner accounts should have an onboarding process that includes the user sending a “partner agreement” email within one week of account entry.
For now, we will just generate tasks for the user who entered the account, but if we wanted to enhance the process even further, we could send those emails out automatically using flows.
Figure 16.41: Selecting a flow type from the New Flow page
You will notice that we now see something different than when we were creating a screen flow. When we created the screen flow it took us directly to the Flow Builder canvas. For a record-triggered flow we are going to have to configure the start element first.
Account
Customer – Direct
Customer – Channel
Channel Partner / Reseller
Installation Partner
Technology Partner
Your screen should look like the following screenshot:
Figure 16.42: Defining the trigger for the flow
What we have done here is set up this flow to run when an account is created if it has a type of one of those five values (if you have modified the Type picklist on the Account you might have different values).
We are optimizing the flow for Actions and Related Records because we are going to create other records as part of this flow. Fast Field Updates would be used if we were just updating fields on the Account itself.
Account: Create Onboarding Tasks
and give it a description. Remember to save your flow after each step.Figure 16.43: Adding a Decision element to the flow
Customer or Partner
Customer_or_Partner
Is this a customer account or a partner account?
Partner Account
Partner_Account
Customer Account
Figure 16.44: Setting the two outcomes of the Decision element
Partner
, and the second outcome will execute in all other cases. If you think back to when we set up the Start element, ONLY accounts that have specific partner or customer types will enter this flow, so every account that is not a partner will be a customer.
Now we have two branches, one for partner accounts and one for customer accounts. Let’s set up the partner account branch first. Thinking back to our business requirements, when a new partner account is created, the system should automatically generate one task for the user who entered the account to remind them to send the partner agreement with a due date one week after the account is entered.
Before we move on to the generation of the tasks, let’s create the formulas we will use for due dates. We need one formula to give us the date one week from now and another formula to give us the date two weeks from now:
Figure 16.45: Adding a resource to the flow from the Flow Builder
Figure 16.46: Configuring the added resource for the flow
fxTodayPlusFourteen
and change the formula to add 14 days instead of 7 days:Figure 16.47: Creating a second formula resource
Figure 16.48: Adding a Data element to the flow
Create Partner Onboarding Task
Create_Partner_Onboarding_Task
Creates a task for the account owner to send the partner agreement with a due date of one week from today
Task
Figure 16.49: Configuring the Create Records component
Subject
Send Partner Agreement
OwnerId
$User > Id
(this will be set to the Id of the user who triggered the flow)WhatId
$Record > Id
(this will set it to the Id of the record that triggered the flow, the account in our case)ActivityDate
fxTodayPlusSeven
Figure 16.50: Filling the field values for the added component
Figure 16.51: Adding a Data element to the Customer Account pathway
Create Welcome Email Task
Create_Welcome_Email_Task
Creates a task for user to send welcome email due one week from now
Task
Figure 16.52: Configuring the element added to the flow
Subject
Send Welcome Email
OwnerId
$User > Id
(this will be set to the Id of the user who triggered the flow)WhatId
$Record > Id
(this will set it to the Id of the record that triggered the flow, the account in our case)ActivityDate
fxTodayPlusSeven
Figure 16.53: Configuring fields for the Create Records component on the Customer account pathway
Figure 16.54: Adding a second Create Records component to issue a reminder to the user
Create Followup Phone Call Task
Create_Followup_Phone_Call_Task
Creates a task for user to make a follow-up phone call
Task
Figure 16.55: Configuring the new Create Records component
Subject
Follow-up Phone Call
OwnerId
$User > Id
(this will be set to the Id of the user who triggered the flow)WhatId
$Record > Id
(this will set it to the Id of the record that triggered the flow, the account in our case)ActivityDate
fxTodayPlusFourteen
Figure 16.56: Configuring fields for the new Create Records component
Save your flow again. We have built the flow and now it’s time to test and distribute. But first, let’s recap:
Figure 16.57: Overview of the completed flow
There are several ways we could have done this, and as your flow skills evolve you will realize that what we just did was not the most efficient way. We could have used formulas to determine task subjects and eliminate one of the Create Records elements.
Once you are advanced enough in your learning to be able to use record collection variables, you will want to do inserts or updates of the same object using one Create Records element (rather than the two we used down the customer account path).
Now we will test the flow using the debug feature. Click Debug in the top-right corner:
Figure 16.58: Selecting Debug from the Flow Builder
Select an existing customer account and see how the debug tool highlights the path the flow went down:
Figure 16.59: Debugging one pathway of the flow
Then debug the flow again with a partner account (you may have to create or update an existing account’s type in your org to do this).
Figure 16.60: Debugging the Partner Account pathway of the flow
Resolve any errors you find when running the debug. Once everything looks good, we are ready to distribute.
Record-triggered flows are different from screen flows. Screen flows generally need to be placed somewhere in the UI (record page, utility bar, button, etc.) to be usable. A record-triggered flow fires automatically based on record updates, inserts, and deletes depending on how it is configured. So all we have to do is Activate the flow:
Figure 16.61: Activating the flow without having to place it in a Lightning app’s UI
Now that the flow is active, go ahead and see it in action. Get out of Setup and go create a couple of accounts, making sure that you are selecting relevant account types on creation. You should see tasks get automatically generated related to these accounts.
Great work! You have just made your users’ lives easier.
We just covered the very basics of Salesforce Flow. It is an incredibly powerful tool and should be used carefully. There are tons of great blogs, Trailheads, and learning materials out there for you to develop your skills further. Here are some basic best practices (there are more best practices once you become familiar with loops, record collections, and other advanced topics):
var[name]
(varAccountId
was an example we used earlier)c[name]
fx[name]
(see the formulas in Example 2: record-triggered flow, such as fxTodayPlusSeven
)tt[name]
st[name]
With these best practices in mind, it is also worth noting that there is a considerable amount more to learn. Here are some things that we did not cover:
There is so much to this tool that an entire book could be written about it, and we just scratched the surface. The goal of this chapter was to introduce you to Flow Builder and get you interested in learning more.
In this chapter we have uncovered one of the most exciting concepts in Salesforce, Salesforce flows. Beginning with an introduction to flows, we have progressed into learning the different flow types in Salesforce, and then the elements used in the Flow Builder. After introducing the Debug tool, we have dived deep into two examples: screen flows and record-triggered flows. For each use case, we have learned how to build, test, and distribute the flow. Finally, we have covered the best practices when building flows, as well as pointing to the vast amount of advanced concepts beyond this book.
In the next chapter, we will continue learning how to automate in Salesforce by turning our attention to approval processes.
Join our community’s Discord space for discussions with the authors and other readers: https://packt.link/rlptF