Greenery and text that says, "Why Admins Should Create Flow Tests."

Why Admins Should Create Flow Tests


Summer ’22 introduces a new feature—Flow Testing!

The Summer ’22 Release brings admins the ability to create tests for record-triggered flows with Flow Testing. This beta* feature is a great productivity gain for admins! First, you create positive test scenarios for your flow in advance. This includes setting up a test record to use and selecting when your flow should be tested. Then, instead of using debug where you manually select the record or set the conditions for your debug, you select the configured test scenario to run it. And voila! Flow Builder runs the flow test for you, showing the path the flow took and the results of your test assertions. This eliminates the need to locate and use a record to test a flow using debug. Who doesn’t want to boost their productivity?!

Previously, if you wanted to test your flow, unless you have coding skills, you would ask your developer colleague to lend a hand and write an Apex test class for your flow. But wait, building flows is a no-code task, so why should testing a declarative automation solution be a code task? Plus, if every time you build a flow you need to involve a developer, that would really slow down your ability to deliver, being dependent on someone else to get the job done. A key benefit of building automation in Flow is that admins can build the automation and deploy it faster to production than it would take a developer to create code, ensure test coverage, etc. Now, with Flow Testing, admins like YOU can build a flow and create automated tests for it without involving developer resources. Let your developer focus their time on true code tasks. It’s a win-win for everyone!

Automation testing is a must

The great thing about automation is that it automagically does things that previously were completely manual. You can use automation to save time doing repeatable, routine admin tasks as well as those done by your business users or customers. When you build automation, it’s important to test it to ensure it works as expected before putting it into action. This is no different than a car manufacturer that builds a brand new car model. They would never skip taking the car on multiple test drives to ensure it works as expected before delivering to consumers.

I’m convinced. How do I set up a flow test?

There are two ways to set up a flow test for a record-triggered flow.

First, we’ll use a record-triggered flow that admin Addison Dogster created to walk you through the setup process. This flow executes when a new cupcake order is created and, based on its order method, will assign the order to either the pickup or delivery queue. If the desired order date/time is Today, an email alert will be sent to the queue indicating the order needs to be completed today.

A configured record-triggered flow.

After you debug a record-triggered flow, click the new Convert to Test button.

Record-triggered flow in debug run.

This takes you to a screen to configure your test. The nice thing about creating flow tests from this screen is it pre-populates the triggering record information for both the initial and updated record with the record data you used to debug the scenario as a starting point.

The Convert to Test button and the pre-populated flow test screen after the conversion.

The second way to set up a flow test is by clicking the View Tests (Beta) button in Flow Builder.

Flow Builder with an arrow pointing to the View Tests (Beta) button.

The first time you set up a flow test, you’ll see a screen that notes the feature is in beta. Click Create to create your first flow test!

Initial beta flow test screen.

This takes you to the screen to configure the flow test. Here, you set the test details, trigger, and path as well as the initial triggering record and assertions.

Flow test creation screen.

Let’s create a flow test!

Addison will walk you through the Pickup is Not Today flow test scenario, which is one of four test scenarios she configured for her record-triggered flow. In this scenario (as shown in the test scenario path below), Addison tests that when a cupcake order is Submitted, the order method is Pickup, and the desired order date/time is Not Today, the flow will assign the cupcake order to the pickup queue and will not send the email alert to the queue.

Flow tested scenario with path highlighted.

Addison configures the Set Test Details, Trigger, and Path tab of the flow test. She provides a flow test label called Pickup Not Today and a description of the test. She sets the test trigger to Created, since this process runs on only new cupcake orders, and sets it to Run Immediately.

Configured Set Test Details, Trigger and Path portion of the flow test.

Next, Addison selects the record to use for test purposes. Using the search function, she’s able to search for the record to use as a starting template. Upon record selection, the fields are populated from the selected record. Addison reviews and makes any needed changes to fields to ensure the record has the appropriate attributes to trigger the test scenario (that is, Submitted status, Pickup order, and the Date/Time Order Desired By).

Configured Set Initial Triggering Record portion of the flow test.

Lastly, we need to configure the assertions. I can hear you now, “Whoa, you’ve lost me! I’m an admin, not a developer. What’s an assertion?!” Simply put, an assertion is a way to compare the actual outcome with the predicted outcome. If they match, then assertion evaluates to true. Otherwise, the assertion fails.

Addison writes the following assertions to ensure the record entry criteria for the flow are met and the expected outcome is achieved:
(Note: These would be equivalent to your entry criteria and post conditions in a user story for the automated process.)

  • Check that the status is Submitted. (This verifies that the record is in Submitted status to trigger the flow.)
  • Check that the order method is Pickup. (This verifies that the record has the Pickup order method to trigger the flow.)
  • Check the variable varPickupQueueId has a value. (This verifies that the lookup of the pickup queue ID was successful.)
  • Check that the email alert was not sent. (This verifies that the email alert was not sent as expected.)
  • Check that the variable varPickupQueueDeveloperName is Pickup_Queue. (This verifies that the record was assigned to the pickup queue as expected.)

Addison also customizes the error message for each assertion so that anyone running the test will know why the assertion failed.

Configured Assertions portion of the flow test.

Once all three sections of the flow test are completed, Addison saves the flow test.

Moment of truth! Will my test run as expected?

After Addison creates her flow test, she needs to run it.

She accesses the Tests (Beta) screen, selects the dropdown for the flow test she wants to run, and selects Run Test and View Details.

The flow test screen with Run Test and View Details selected for a test.

The flow test runs and highlights the path the test took. Success! Addison confirms all six assertions passed as expected. Woot woot! From now on, when Addison needs to test the flow, she can just run the test. No more setting up the test data or remembering the scenarios to test. Way to go for testing efficiency!

Note: If Addison makes an enhancement to this flow in the future, she’ll need to update the associated test accordingly.

The flow test run.

Important things to note

Flow Testing is in beta, so it doesn’t have all the bells and whistles yet. Here are a few things to note as you use this feature.

  • You can only test assertions for the “happy path”—positive testing.
  • You can only create flow tests for the Run Immediately path.
  • You can only create flow tests for create, update, or create/update record-triggered flows. Delete record-triggered flows are not yet supported.
  • If you have a scenario that requires a record to reflect a date set to Today, you’ll need to edit the test and set the date to Today manually before running the test. Otherwise, it will fail, as the record was set to a date that was today’s date at the time the test was created.
  • You cannot deploy flow tests from a sandbox to production via change sets but you can use SFDX.
  • Flow tests do not run automatically with deployment.

Start testing!

Get started on creating and running tests for your flows today! Establish the entry criteria for your test, set up the record to use for your test, and, lastly, set up your assertions. It’s as simple as one, two, three, test! Give this new feature a spin the next time you create a record-triggered flow.

Tell us what you want to see

What would YOU like to see this Flow Testing feature do? Here’s where your feedback counts. Drop a post in the Salesforce Automation Trailblazer Community to share what you would like to get out of this feature.


*When a feature is in beta, this refers to the phase of a feature that is rolled out publicly for testing. Beta features are normally given limited support as they are not yet fully functional or finished, so we recommend getting hands-on with these features in a sandbox.

Einstein next to text that says, "Be an AI-Minded Salesforce Admin."

Be an AI-Minded Salesforce Admin

Understanding the fundamentals of artificial intelligence (AI) is critical to being an #AwesomeAdmin. This technology has opened up broadly and both people and businesses are finding new and inventive ways to weave it into products and our lives. There’s no better time to get up to speed on AI and how you will be able […]

The admin Learn Moar Trailhead Community badge next to text that says, "#2 Reactive Screen Components (Beta)."

Reactive Screen Components (Beta) | Learn MOAR Summer ’23

In Summer ’23, admins can start taking advantage of reactivity with reactive formulas. Read this blog post to learn why reactive screens will transform the screen-building game for Flow and for the Salesforce platform as a whole. Then complete the Learn MOAR Summer ’23 for Admins trailmix to earn a special community badge. Before we […]


How #AwesomeAdmins Help Salesblazers Sell as a Team

Selling has become a team sport, with 81% of reps saying team selling helps them close deals. For Salesforce Admins, enabling a team selling approach can create both opportunity and some complexity. Team selling weaves in many of the core responsibilities admins practice each and every day, such as permission sets, security, and data management. […]


Have an Idea for a Story?

We are all about the community and sharing ideas.
Do you have an interesting idea or useful tip that you want to share?