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.

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

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 second way to set up a flow test is by clicking the View Tests (Beta) button in Flow Builder.

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!

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.

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.

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.

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

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.

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

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.

Resources

• Salesforce Help: Summer ’22 Release Notes: Test One, Two, Three, Flow (Beta)
• Trailhead: Salesforce Automation Trailblazer Community Group

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