Don't Forget About Testing as you Migrate to Flow

One of my favorite Salesforce people on social media is Jodi Hrbek and she recently wrote a great LinkedIn post on migrating to Flow.?

Here's a link to her post

Adding to her list of considerations, Testing is going to be an important (and probably too often overlooked) part of the migration effort. With that in mind, here are a few of the considerations for structuring your testing efforts as you migrate your Salesforce org to Flow. (And if you're wondering what all this "migrating to Flow" stuff is about: Elements.cloud has an excellent article on the topic).

1. Scope of this Article: Test Case Definition

This article will focus on test case definition (specifically Functional Test Cases) for migrating legacy automations (like workflow rules & process builders) to Flow. This article will not focus on the various ways test cases may be executed (manually, via automation, etc):

• This article is agnostic of your DevOps process. But regardless of your particular process, you should be building and testing your Flows in a sandbox and moving the changes into production using some type of tool (whether that’s Salesforce change sets or a DevOps platform). No changes should be made manually in production(!).
• Similarly, there are different ways that test cases can be executed: manually or via a tool. Either way, test cases should be defined thoughtfully. This article will focus on the test cases definition (not the various ways the cases could be executed).
• There are many types of software testing. I’m going to focus on a few types here that are particularly relevant to migrating legacy Salesforce automations to Flow. ?

2. Assessing Risk

In order to determine your testing needs, you should consider your automations along two dimensions: Complexity and Business Impact.

• Complexity: This refers to the logical and technical complexity of your automations. All things being equal, the higher the complexity, the higher the likelihood of unintended outcomes and defects.
• Business Impact: This refers to the negative effect on the business that would result from defects. Let's consider two examples. In the first example, we have an automation that impacts a small number of internal users on a business process that is not time sensitive and does not impact revenue directly. This automation would likely be considered low business impact. Contrast that with a second example where an automation is used in an external facing Experience Cloud instance where a large number of customers place orders. Client facing + high volume + direct revenue impact = very high business impact.

These dimensions are relative, but the higher the complexity and larger the possible business impact, the more you should be testing. It isn't feasible to test every possible scenario so focusing on Complexity and Business Impact will give you a lens through which to prioritize your testing efforts.

3. Focus on Functional Testing

For many Salesforce orgs, Functional Testing will be the core type of testing needed for migrating legacy automations to Flow. Functional Testing is all about testing business scenarios and making sure that a given input yields the intended business output.

Functional Tests should be understood by business users and technical users, so they also can be a useful tool for communicating scope of effort, achieving consensus, and getting input across tech and business teams.

4. An Example

Let’s say we’re working on a Salesforce org for a University. And they have a legacy automation that creates a task when a Student registers for a Business course. We need to create a Flow that will replace this legacy automation. Here's the spec of the use case:

• We have a custom object called Course_Registration__c that manages a student's registration/enrollment in a course. The Course_Registration__c object has a required lookup to the Contact object (the Contact represents the Student). The Course_Registration__c object has a picklist field (required & restricted) called School__c which has the following values: Business, Liberal Arts, Social Work.
• When a Course_Registration__c record is created and Course_Registration__c.School__c="Business", the Flow will create a Task record that has a due date = today()+7.
• The Flow should assign the Task to the User in the Course_Registration__c.Contact__r.Advisor__c. If the Advisor__c field is blank or the User is inactive, the Flow should assign the Task to the Contact.Owner.

Here is an example of a few basic functional test cases that could be used to test the logic above. Notice that the Criteria and Expected Outcome are broken out to separate the triggering conditions/criteria (the input) from the Expected Outcome (the output).

5. Types of Functional Tests

As you write your test cases, consider the following types of functional tests:

• Positive Test Cases: Positive Test Cases are scenarios where the input is expected/known and the result is an expected outcome. In the example above, Scenarios 1 - 4 are Positive Test Cases.
• Negative Test Cases: Negative Test Cases are scenarios where the input is unexpected and will result in an error or kick-out. The purpose of Negative Test Cases is to make sure that unexpected inputs result in user friendly error messages to end users (no Flow exceptions!) and/or notifications to admins. We want to avoid things like: End users receiving system errors or Admins being unaware that errors have occurred. In the example above, Scenario 5 is a Negative Test Case.
• Regression Tests: Regression tests are scenarios that are not directly related to the automation, but have tangentially related functionality which may have been unintentionally impacted by the automation. Regression test make sure that existing functionality works as it did prior to the automation. In the example above, Scenario 6 is a Regression Test Case.

Testing: An Important Part of the Journey to Flow Town

Like Jodi said in her post: us in the Salesforce community are on the road to Flow Town. There's a ton of energy in the community behind having a single, (very) robust declarative automation tool. Testing will be an important part of the migration effort by increasing expected outcomes and minimizing unexpected outcomes and their impact. It's also likely that writing test cases may help you write better Flows and consider scenarios/criteria that you might not otherwise.

While testing is easy to overlook, a well thought out and executed test strategy will pay dividends for your users (everything will work as expected!) and for you (fewer support requests and more happy users!).