What is a flow in Salesforce?

Lightning flows (or simply flows) help you automate complex business processes and manual data entry. Flows let you work smarter, not harder, by saving your users time and making sure the required tasks are accomplished correctly.

As a Salesforce admin, flows are one of the most powerful tools in your toolbelt — when set up properly, flows make you look like a rockstar to your sales team, but if your flows aren’t configured correctly, they might be difficult to manage or make a mess (also kind of like a rockstar).

This guide will teach you everything you need to know about flows. Let’s dive in!

What is a flow in Salesforce?

In Salesforce, a flow is a tool that automates complex business processes. Simply put, it collects data and then does something with that data.

Flow Builder is the declarative interface used to build individual flows. Flow Builder can be used to build code-like logic without using a programming language.

Flows fall into five categories:

Screen Flows:

• These are flows that have a UI element and require input from users. These types of flows are either launched as an action or embedded as an element on a Lightning page.

Schedule-Triggered Flows:

• These autolaunched flows launch at a specified time and frequency for each record in a batch, and they run in the background.

Autolaunched Flows:

• Run automated tasks with this flow type. Autolaunched flows can be invoked from other flows (subflow), process builder, from within an Apex class, from a set schedule, from record changes, or from platform events.

Record-Triggered Flows:

• These autolaunched flows run in the background either before a record save or after the record is saved when a record is created, updated, or deleted.

Platform Event-Triggered Flows:

• When a platform event message is received, these autolaunched flows run in the background.

Check out this example of a schedule-triggered flow, pulled from a well-known Salesforce group:

When/why should I use a flow?

If you need to generate a new automated business process, or user guided experience that does not reach the complexity threshold for Apex Code, then flow is your go-to tool. If you are modifying an existing process that was built with Process Builder or workflow, then you should consider a number of factors when deciding whether to modify the existing process or migrate it to Flow. 

Flows are able to create, edit, and delete records in Salesforce, send emails, show relevant data and gather input from users, and generate outbound messages.

When should I not use a flow?

Generally, you should not use a flow in the following situations:

There is complicated logic involved that is better managed with Apex code. An example of this is the flow shown in the Overview section. The logic in this flow is so complicated that it makes debugging a pain, plus it makes documenting and managing the flow difficult.

Your Salesforce edition limits how many flows you can create. Note, it is possible for developers to write Invocable Apex methods that you can call from a flow (similar to calling a subflow). Using this pattern, you can offload especially complex processes to Apex, but still have your flow builder maintain control of the overall process!

Essentials and Professional editions of have a limit of five processes (per process type) and flows (per flow type) in each organization. For most logic in these editions, it is easier to use a process.

How do I create a flow in Salesforce?

Open Flow Builder. From Setup, enter “Flows” into the Quick Find box, select Flows, and then click New Flow. Select the Flow Type, then click Create.

The type of flow you create will impact your experience. For scheduled and record triggered flows, you can access an auto created global variable called $Record. This gives you access to all of the fields on the record that triggered the flow(and its parent records!!!). If you create an autolaunched flow, you’ll have to create any required input variables yourself.

Once you get your inputs setup, you can click the ‘+’ button after the start element - you will have a choice elements to carry out your business processes. Each element represents an action that the flow can execute. Examples of such actions include reading or writing Salesforce data, displaying information and collecting data from flow users, executing business logic, or manipulating data.

(For some more detailed flow building examples - subscribe to our newsletter! Just scroll to the bottom of this page to find the signup link.) 

Save your flow.

After you build a flow, make sure that it’s working correctly by thoroughly testing it. Once you’ve tested it, activate the flow. You’re now ready to distribute the flow to users.

Pro tip: Flows can be executed in several ways, depending on who the flow is designed for. Internal users, external users, or systems can run a flow, or a flow can be deployed for another organization. Just remember, no matter how you execute it…you’ve got to go with the flow.

Flows vs. Apex

Apex code requires a developer and Sandbox to deploy, meaning it can only really be built in organizations using a Professional or above edition of Salesforce. Flows can be built in all editions. While a Sandbox is not required to get a flow into a production environment, it is advisable that flows that leverage the full power of the tool are built and tested in a sandbox before being deployed to production.

Apex is not available in Essentials, and some Apex features are limited in Professional. Organizations with Enterprise and above have no Apex limitations, but flow features are not limited based on the edition. Apex code requires constant development and discipline to maintain. Flows require less work to keep up-to-date.

Flows can be built by admins, while Apex code is typically built by developers only. Apex code is considered a tool of last resort. Flows are simpler and should be used before Apex code.

If the logic is too complex, Apex code should be used. Each release brings new features that reduce the use cases that require Apex, but there are still some situations where Apex will bring a performance boost and should be considered.Renewal generation, Opportunity Product, and other pieces of automation that were traditionally built as Apex code can now be built as flows, preserving code space for projects that require Apex. 

Apex code should be used in the following scenarios:

• Your flow requirements require nesting loops
• Your flow requirements require get elements inside a loop
• You are working with very large data volumes
• You need custom-built integrations with other systems (such as a connection to a SQL database that requires bi-directional syncs).
• ERP integrations are involved.
• You need to log or present a custom error message if the automation fails or doesn’t find what it’s looking for. (However, you can do this in some cases with flow!)

Considerations for migrating from Process Builder to Flow:

With the Winter 23’ release, admins are no longer able to make new workflow rules, and Process Builder will be soon to follow. New automation should be built in Flow and migrating existing workflows and processes should be a strong consideration. Changing existing automation comes with its own risk. Consider the following when determining the right time to make the move.

Situations that indicate you should migrate soon:

• You have more than one process builder per object
• Your existing processes often fail or create errors
• Your existing processes are simple
• You are introducing a significant amount of new functionality
• You have well designed acceptance criteria to test your new automation against your existing processes

Situations that indicate you should consider holding off your migration:

• You have complex, stable processes that meet current business needs
• You do not have clear testing requirements to confirm your new Flows replace the migrated workflows and processes. 
  

Testing flows

To test a flow, click the Debug button on the canvas, input your variables, and click Run. Then run through the flow to make sure it works properly. This process is especially helpful with screen flows.

Note that as of the Winter 2021 Salesforce release, a beta feature called Debug on Canvas is available. This feature makes flow debugging easier by visually demonstrating the path your flow will take when it runs. It also shows query limits of the flow in the debug details. Additionally, debugging now offers two more options than it did previously: Run flow as another user, and Run flow in rollback mode.

Where is the Flow Builder in Salesforce?

To find the Flow Builder in Salesforce (Lightning), navigate to Setup > Process Tools > Flows.

What are the different Flow Types in Salesforce?

Auto-Launched Flows with No Flow Trigger

These flows don’t require user interaction, and they don’t support screens, local actions, choices, or choice sets. The available distribution methods available are:

• Flow actions
• Lightning pages
• Lightning community pages
• Custom Aura components
• Custom Lightning web components
• Custom buttons or custom links
• Web tabs
• Direct flow URLs
• Visualforce pages
• Lightning out
• Embedded service deployments

Auto-Launched Flows with a Schedule Trigger

These flows only run from a schedule that the user sets. They don’t support user interaction, screens, local actions, choices, or choice sets. The available distribution methods are:

• Processes
• Custom Apex classes
• REST API
• Web tabs
• Custom buttons or custom links
• Visualforce pages

Screen Flows

Screen flows require user interaction because they include screens, local actions, steps, choices, or dynamic choices. Screen flows don’t support Pause elements. A schedule-triggered flow only runs at the scheduled time and frequency.

Auto-Launched Flows with a Record Trigger

These flows are designed to quickly make simple changes to a record when the record is created, updated, or deleted. They can also be configured to make those changes either before or after the record has been saved to the database. In a before-save flow, the supported elements are Assignment, Decision, Get Records, and Loop. After-save flows have access to all flow capabilities, but they cannot launch sub flows.

User Provisioning Flow

User provisioning flows provision users for third-party services. You could use this flow type to customize the user provisioning configuration for a connected app, linking Salesforce users with their Google Apps accounts. A user provisioning flow can only be implemented by associating it with a connected app when running the User Provisioning Wizard.

Field Service Mobile Flow

These flows require user interaction because they have one or more screens.

Field Service Embedded Flow

These flows require user interaction because they have one or more screens.

Contact Request Flow

These flows require user interaction because they have one or more screens. Use one of the following Experience Builder components to add this flow:

• Contact Request Button & Flow (launch the flow in a popup window)
• Flow (embed the flow directly on the page)

For more on Flow Types in Salesforce, check out the official documentation.

What is a flow interview in Salesforce?

While a flow is an application built by your administrator that asks you for inputs and does something in Salesforce based on those inputs, a flow interview is a running instance of a flow.

For example, a flow could provide a call script for customer support calls using the information you provided to create a case. What the flow does with the information you provide is entirely up to your administrator.

When you run a flow interview, whether through a link, button, or tab, you’re running a single instance of a flow. If the terminology is confusing, consider the difference between a record and an object. You create an account record, which is a single instance of the account object that your administrator customized.

It is a good idea to monitor the Paused and Failed Flow Interviews list available in Setup>Paused and Failed Flow Interviews. This pair of lists is quite helpful. The paused flow interviews lets you check in on flows with time based actions or screen flows that users have not completed. The failed flow interviews list is still more helpful as it shows you flow errors along with the debug log for the flow interview. This should be your first stop when troubleshooting a flow.

Read more about flow interviews in Salesforce’s documentation.

How do you call a flow from a button in Lightning?

Since Winter 2018, Salesforce has offered an easy way to trigger a flow using a Quick Action button in Lightning.

Note: Only screen flows or field service mobile flows may be launched from a Quick Action button.

Create a custom action for the record in question by navigating to Object Manager > (Object Name) > Buttons, Actions and Links. Select “Flow” as the type for the custom action, configure the custom action to reference the flow, then name it. Then add the custom action to the page layout of your choice.

Common mistakes made when designing flows

We see a lot of flows here at Kicksaw, and we build even more of them. Here are some common and avoidable mistakes we’ve identified:

• Using the wrong field or variable
• Not checking for null values
• Putting Get, Create, Update, or Delete elements inside of a loop element
• Referencing objects or fields that an end user may not have access to
• No access to running flows
• Using Get elements to get data that is available through the $Record or $RecordPrior in a record or scheduled trigger flow
• Hardcoding record Ids
  

Further Salesforce flows documentation

We hope you learned a lot about the power of Salesforce flows in this article, but if you need more help, reference the official documentation.

For further learning, we also recommend completing the Build Flows with Flow Builder trail on Trailhead, and we encourage you to read more about Flow Builder.

Better yet, reach out to us by filling out the Contact Us form below! We’d love to help in any way we can.

‍