Make Sure Your Flow Works

Learning Objectives

After completing this unit, you’ll be able to:

Identify test cases for a flow.
Explain what a flow interview is.
Test a flow from Flow Builder.

As an admin or developer, you know you should test all customizations before rolling them out to users, and flows are no different. Testing lets you fine-tune the flow’s behavior, identify and fix bugs, and otherwise make sure your users have a successful experience. And of course, you also benefit, because you’re much less likely to spend time later responding to panicked emails from your users.

Before You Start

Before you can complete this module, make sure that you complete the Flow Builder module. The work you do here builds on the concepts and work you complete in those modules.

Create a Test Plan

Before you start testing, draft a list of test cases, and identify what you expect the result to be. Consider things like:

When you expect actions to occur
When you expect actions to not occur
How formulas should resolve

For the “New Contact” flow you’ve been working on, there are four major test cases.

Toggle setting	Matching record	Expected result
Deselected	Doesn’t exist	A contact is created Confirmation screen includes a working link to the record A Chatter post was created on the record’s feed Confirmation screen and Chatter post specify “created”
Deselected	Exists	A contact is created Confirmation screen includes a working link to the record A Chatter post was created on the record’s feed Confirmation screen and Chatter post specify “created”
Selected	Doesn’t exist	A contact is created Confirmation screen includes a working link to the record A Chatter post was created on the record’s feed Confirmation screen and Chatter post specify “created”
Selected	Exists	A contact is updated Confirmation screen includes a working link to the record A Chatter post was created on the record’s feed Confirmation screen and Chatter post specify “updated”

Now that you know what to test for, let’s see how to test the flow.

Testing Options in Flow Builder

You don’t have to leave Flow Builder to make sure your flow works. The button bar includes two buttons for running a flow: Run and Debug.

Run runs the most recent saved version of the flow that you have open.
Debug does everything that Run does, but with some superpowers thrown in. It lets you enter values for the flow’s input variables and display debug details while running the flow. That way, you can verify how the flow processes data.

Tip

Unless you need to test how your flow works in Classic runtime, always use Debug to test your flows. While Debug always uses Lightning runtime, Run obeys the Enable Lightning runtime preference in your org’s Process Automation settings.

When you click Debug and opt to show details, you see the flow’s first screen (1) and the debug details (2). As you step through the flow, new details are added to the right-hand panel.

An instance of the “New Contact” flow in debug mode.

Introducing Flow Interviews

Each time a flow runs, a flow interview starts. A flow interview is an instance of a flow.

Think of Choose-Your-Own-Adventure books. A flow is like the book itself, which provides choices to the reader and instructions for each choice. A flow interview is like the reader. As you read, you make choices and follow the instructions for those choices. Each time you or another person reads the book, you can take a different path through the book and experience a different story.

The same goes for interviews. Based on the data provided for that interview, either by input variables or input components on a screen, each interview can take a different path through the flow and result in different actions being performed.

To see interviews in action, let’s verify the four cases from our test plan.

Test Your Flow from Flow Builder

From Flow Builder, click Debug. Make sure that the second checkbox is selected. Otherwise, you won’t see any debug details. Since this flow doesn’t have Subflow elements or input variables, don’t worry about those settings.
Click Run.
Validate the first test case.
1. Enter a first and last name, and choose an account.
2. Leave the toggle unselected.
3. Click Next.
4. Review the debug details.
  - The first card identifies who started the flow interview. Since you started it, you should see your name and user ID.
  - The second card summarizes how the inputs from the first screen was stored for the flow interview to use. For example, because you left the toggle unselected, the {!updateExisting} variable was set to false
  - The third card summarizes how the “Update If Existing?” decision was evaluated. Because {!updateExisting} was false, the interview took the default path. On the canvas, that’s the connector labeled “No”, which goes straight to the Create Records element.
  - The fourth card summarizes the “Create Contact” element. The interview used the values in the {!contact} variable to create a contact record.
  - The fifth card summarizes the Post to Chatter action. The message posted was “This contact was created”
5. Verify the expected results for this test case.
  - The confirmation screen specifies “created”.
  - The link goes to a new contact. The contact’s name matches what you entered and is a child of the account you selected.
  - On the contact’s Chatter tab, a post specifies that this contact was “created”.
Repeat for the other three test cases. For cases that include a matching record, use the same first name, last name, and account you used for the first test case.

If any of the test cases have unexpected results, use the Debug Details to backtrack and figure out what went wrong. Once all the test cases pass, you’re ready to put the flow in your users’ hands.

Resources

Salesforce Help: Debug a Flow in Flow Builder
Salesforce Help: Considerations for Debugging Flows in Flow Builder

トピック