No matter where you are in your Salesforce Flow journey, or how much you’ve used it, you should know that you need to test any automation or functionality before deploying it into a production environment (and after deployment to make sure there are no anomalies!). As Salesforce Flow will be the sole declarative automation tool inside Salesforce going forward, this rule applies here as well.
Recently, there have been a number of enhancements to how you should be testing your record-triggered flows – this is following new tools and releases. We will go through a number of these tools and best practices for using them, as well as some design practices you can keep in mind to help reduce the number of errors you come across during a Salesforce Flow test.
Debug Tool
The Flow Debug tool has been around for a long time and has been a great way for Flow Developers to simulate a flow being run from multiple perspectives, while seeing a breakdown of how each element has been hit.
While the debug tool has allowed Flow Developers to test their new or modified declarative automations for years, it has remained a rather manual and cumbersome process. Flow Developers would need to configure the debug run each and every time before it was run, and did not have the ability to save specific runs with specific variable values.
Apex allows for both individual Apex method runs and persisting tests in the form of test classes. Salesforce has long been asked when they would release a similar tool for record-triggered flows, and with the summer ‘22 release, they have provided an answer for that question in the form of Flow Tests.
Converting Debug Run to Flow Test
Believe it or not, you can actually create a debug to run a Salesforce Flow test with just a few clicks. This means that, even if you run a one-off test and decide afterwards that you want to run it on multiple occasions, you don’t have to start from scratch.
Once you have successfully executed your debug run, you will notice a new “Convert to Test” action along the top-right of the page – next to “Edit Flow”. Click “Convert to Test” and the new test screen will pop up in a modal for you to convert the debug run to a flow test.
It’s worth noting that if your debug run does fail for any reason, the “Convert to Test” button will be grayed out and you will not be able to create a new test from it. You will need to make sure your flow is able to successfully complete the debug run before you create a flow test from it.
Record-Triggered Flow Testing Tool
The recent Summer ‘22 release included a new tool to allow Flow Developers to easily perform a series of batch tests for record-triggered flows (this tool is in Beta in the Summer ‘22 release). Flow Developers can create multiple tests to be performed either one by one or all together against a record-triggered flow to see if it is performing as anticipated.
Flow Developers can use flow tests to create automated testing scenarios that align back to business requirements to ensure that the record-triggered flow that has been created is doing what the business is expecting. They can also be used to ensure that existing functionality is not broken when a change is made to a flow.
Creating User Stories to Test Record-Triggered Flow
As a Flow Developer, you should work closely with your business to carefully understand the reason you are being asked to create automated functionality with Salesforce, and you should translate these requirements into User Stories.
User Stories follow a specific format: “As a {persona}, I want to {task} so that {goal}”. An example of this would be: “As a Sales Team Member, I want to be able to record new lead information so that I can keep track of my dealings with them”.
These User Stories are the reasons you are building a flow in the first place, so it makes sense to make sure the requirements are achieved by the flow you build. Creating flow tests that align to User Stories are the perfect way to do this. You can easily test and retest them all at once when changes are made and see a list of those that passed, as well as those that have failed.
Thinking abstractly, flow tests follow a similar format to User Stories in that you are giving a number of inputs, setting an action to occur, and then creating expected results based on an action.
Apex Tests Best Practices Apply to Flow Tests
Apex tests function very similarly to flow tests: write a test class against your Apex Methods, set your assertions (a variable and what you expect the variable values to be following an action), and then run the method as a test. There are a number of best practices from Apex Test Class writing that should also be applied to flow tests as well (taken directly from Salesforce’s documentation).
You should try and cover as much of your flow as possible with tests. This not only ensures that what you are building is directly related to the requirements that drove the innovation in the first place (assuming you used User Stories as suggested), but it will also minimize the number of errors that your end users will see.
If your flow uses Decisions, be sure to create tests that apply to each branch. Once again, this ensures that all paths within your flow are tested thoroughly. Remember to also include negative tests (test against scenarios that will happen, and also against scenarios that won’t/shouldn’t happen to ensure they are handled as expected as well).
It’s also worth pointing out that Flow Tests function similarly to the Debug Tool and Apex Tests – any changes you apply to records do not actually commit, so you don’t need to do a cleanup afterwards.
And always, always build your Flows in a Sandbox or Developer org before deploying them into production – this should go without saying. Test your flows vigorously before pushing them into production to ensure there will not be any adverse actions performed as well.
Designing Flows to Pass Testing Using Fault Paths
Ensure that when you are designing your flows, you are planning for errors to occur at certain points (such as Data Elements – Create, Update, Get, or Delete), and you are preparing for these errors by using functionality like Fault Paths. I’ve written about Fault Paths within Salesforce Flow before – you can read more about it here.
What About Other Flow Types?
Unfortunately, the new Flow testing tool only works for record-triggered flows at this stage. This is something Salesforce will likely expand to schedule-triggered flow, autolaunched flow, and platform event-triggered flow in the future. However, for the time being you will need to continue to use alternate methods of making sure these other Flow types function properly (such as using Debug Flow, performing manual scenario-based testing, etc.) before pushing them to production.
Summary
Developing flows to meet the requirements of your business is just as important as testing those flows before deploying them into production.
You will ensure that you are not creating more damage than value for your business by making sure that your flow doesn’t behave in an unexpected way; by performing a Salesforce Flow test, you will be ensuring a good end user experience for your internal business users, external partners, or customer users.
Comments: