This post was last updated on 04/16/24.

Overview

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 tool belt — 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 six 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), 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 or after a record save 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.

Record-Triggered Orchestration Flows

• Orchestrations allow you to create a multi-step and/or multi-user process when a record is created or updated.

Check out this example of a screen flow that takes care of employee recognition!

When/why should I use a flow?

Flow has become your one-stop shop for configurable automation in Salesforce. If you need to generate a new automated business process or a user-guided experience that does not reach the complexity threshold for Apex code, then Flow is your go-to tool. 

Legacy tools such as Process Builder and Workflow rules should no longer be used for new automation. If you are modifying an existing process that was built with Process Builder or Workflow, then it may make sense to edit the process in its current tool in the short term. However, with the end of support announced for December, 2025, migrating these processes to Flow is a high priority.

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:

• You do not have a well-defined understanding of the business process that you are automating.
• There is complicated logic involved that is better managed with Apex code. If the logic is so complicated that it makes debugging a pain, or it makes documenting and managing the flow difficult, you will likely need Apex for your solution. Please note, though, that 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 Flow Builder maintain control of the overall process! Flow is constantly improving, and as new features like collection filtering and sorting get released, there are fewer situations where Apex code is specifically required.
• Your Salesforce edition limits how many flows you can create. Essentials and Professional editions 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 set up, click the + button after the start element — you will have a choice of 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. 

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.

Another pro tip: Flows have two layout modes. Auto layout is a highly accessible format for new flow builders and for accessibility tools like screen readers. We recommend using auto layout whenever possible, as it promotes standardization and readability.  Even so, we sometimes switch to the free-form mode if we need to make a significant number of changes to a flow — specifically if changing the order of elements.

For some more detailed flow building examples, as well as a wealth of other Salesforce insider tutorials and knowledge-shares every month, subscribe to our newsletter!

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, we recommend that, particularly for powerful flows, you build and test in a Sandbox before deploying flows 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. Additionally, Apex code requires constant development and discipline to maintain, whereas flows require less work to keep up-to-date.

Flows can be built by admins, while Apex code is typically built by a developer. For simple business logic, Flow is preferred over Apex code, but Apex definitely has a place in solving complex problems and managing tighter control over automation in an enterprise setting— flows are simpler and should be used before Apex code.

If the logic is too complex, though, 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 over Flow. 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 include nesting loops that cannot be eliminated by using the filter or sort collection actions that became available in Spring ’22.
• There is an existing trigger framework on an object.
• 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 that require more than a simple callout to an external service.

Flow: the Automation Tool of the Future

Admins are no longer able to make new Workflow rules and Process Builders. Any new automation should be built in Flow, and migrating existing workflows and processes should be a strong consideration. This is increasingly true now that Salesforce has announced the end of support for Process Builder and Workflow rules in December, 2025.

Considerations for Migrating to Flow

Whether you have two or three simple processes/rules to migrate or a highly orchestrated web of automation crafted over 10 years, if migrating to Flow from Workflow or Process Builder, you should begin your migration process by documenting the existing automation and creating a Sandbox. Salesforce provides a migration tool to get you started and there are other third party tools as well. 

Migration tools can take a lot of the tedious work off of your plate, but they should be used with caution. Migrating to Flow provides an opportunity to evaluate the following:

• Do we still need the existing automation?
• Are there any pain points with the existing solutions that could be resolved with the better tooling provided by Flow?
• What is the minimum number of record-triggered flows that we need to meet our use cases?
• Are there small pieces of business logic that reoccur and can be combined into a subflow?

Once you (and hopefully your team of end user testers) have verified that the migration is ready to go to production, generate a timeline and communication plan for the deployment. In addition to activating your new flows, you will need to deactivate any workflows or processes that are being replaced. For orgs with a large volume of processes and workflow rules, consider one of the following deployment strategies:

• Use a custom setting in the filter for the processes so they can all be disabled at one time
• Plan your migration during low system usage time and/or schedule a moratorium for edits during a time period that works for your business
• Use a deployment or migration tool to update the status of the processes and workflow rules to Inactive
• Cover your flows with unit/Apex tests so they can be deployed as Active

Migration can be a huge undertaking with a large amount of dependencies. Consider working with an implementation partner who has a lot of experience designing scalable automation (such as Kicksaw!).

Debugging Flows

To make sure your flow functions as expected, you can 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 ’21 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.

Use Flow Tests to Automate Your Tests

Record-triggered flows give you that ability to configure flow tests to help automate your testing. With flow tests, you can set a starting record, modify its values, and run it through your flow. At the end of the flow test, you configure assertions to verify that the expected behavior occurred.

For those who are unfamiliar with unit tests, a quick example will be useful. Let’s say you have a record-triggered flow on an Opportunity that changes the account’s Type to ‘Customer - Direct’ when the Opportunity is marked ‘Closed Won.’  You can select a test record then use the interface to update the stage to something that is not a closed won stage.

Next, configure the updated record to be closed won so that the flow will fire. The flow test will simulate the record update. For our use case, we will want an assertion to check if the Account Type is now ‘Customer - Direct.’ 

The flow test will simulate the record update. For our use case, we will want an assertion to check if the Account Type is now ‘Customer - Direct.’ 

Considerations for Flow Tests

• You can’t update related records in the interface, so flows that require specific conditions across several objects may fail if related data is changed.
• Plan to use the ‘Equals’ operator for your assertions, as the tool limits the ability to reference flow variables when using the ‘Does Not Equal’ operator.
• For highly complex unit tests, consider using Apex tests.
• Subflows (autolaunched) are not supported, but they can be tested if they are referenced by a record-triggered flow.

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. A schedule-triggered flow only runs at the scheduled time and frequency. Screen flows include a wide variety of components so that you can tailor the user experience for your guided process. Below are a list of screen flow options along with a common use case:

• Display Text gives your users formatted instructions tailored to the business process you are designing.
• Input Components like text, checkboxes, drop, picklists, and dates allow you to accept information from your users with any data type (except time) that Salesforce supports for a custom field.
• Data Table dynamically shows a list of available products available for a specific opportunity type.
• Display Image improves the UI by adding a branded logo.
• Lookup selects a record that can be modified or used as a parent record.
• Slider grabs a CSAT or NPS rating from your customers using a sliding UI.
• Toggle ups your UI game by using a toggle instead of a checkbox to determine the next screen your user sees in your business process.
• Repeater allows users to add any given number of child records to an object and loop through their inputs.

Autolaunched 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.

Record-triggered flows are very powerful, but are often the source of the most frustration. If you have an unhandled fault in your flow, it can prevent your users from saving information. This is especially important to note if you are triggering on a flow that is updated by an integration. To prevent data loss, it is a best practice to fire these flows on an asynchronous path. This will allow the save to occur even if there is an unhandled fault in your flow.

Autolaunched Flows with a Platform Event Trigger

Platform events are used to connect business processes in Salesforce and external apps through the exchange of real-time event data. Traditionally, this type of information is handled by developers, but with a platform event-triggered flow, you can use the power of flow to handle integration information.  

One possible use case is handing SMS events. If you are using an external provider to send SMS messages to your contacts and you want to see these messages reflected in Salesforce, you could configure a Platform event to store information like the message content, contact name, the phone number, and even the contact or lead Id if it is available in the external system. When an SMS message occurs, your provider can generate a platform event and you can create a record for this message if the lead or contact exists — and even create a new lead or contact if you don’t identify someone by name or phone number.

Record-Triggered Orchestration Flows:

Record-triggered orchestration flows allow you to assign a process or processes to a user or group of users when an action happens on a record. When the orchestration fires, a custom screen element shows up on that record for the assigned user. When the user completes their process, the next step in the orchestration is carried out.

A great use case for an orchestration flow is generating a series of steps to take when an opportunity moves to Closed Won. Getting the signatures is huge, but now it is time to provide your excellent service to your new customer. Using orchestration, you can assign a project spin-up to your Customer Success team, an invoicing task to your Finance team, and a follow up thank-you activity to your Sales rep.

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 list 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.

Showing A Screen Flow to Your Users

Using a Quick Action

Screen flows or Field Service Mobile flows may be launched from a Quick Action button, giving you the power to customize a business process based on a specific record in Salesforce.

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. Add the custom action to the page layout of your choice. If you name a text or record variable {!recordId} and mark it for input, your flow will automatically populate that variable with information about the record the user is on when they click the button.

On a Lightning Page

Screen flows can be added to a Lightning home or record page. When you drag a flow onto the Lightning page canvas, you can populate the input variables of the flow. This input information can contain information about the record you are viewing if the flow is on a record page.

When a Lightning record page with a flow is opened by your user and the flow is on the primary tab/page, the flow always runs. For resource-heavy flows, consider putting your business process on a tab that is not visible when the page is loaded to improve page load times.

In a Digital Experience Site

Similar to Lightning record pages, screen flows can be added to your Digital Experience site by adding them to site pages and configuring the correct input variables.

Special consideration should be given to permissions for Digital Experience users and site guest users. In order for your flow to work correctly, any user or guest user must have access to the records that may be displayed or manipulated by the flow, and they must have permission to run the flow.

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
• Deploying flows without testing them as the users who will use them
• 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. And if you want to start a discussion on how Kicksaw can leverage the power of Flow (plus the rest of Salesforce) to bring real value to your business, we're eager to start that conversation as well.

‍