If you read our Test for Outcomes with Flow Testing Upgrades post, then you’re familiar with creating tests that will determine if the flow executed — not just without error, but having reached the right conclusion based on data. Using data to validate outcomes mirrors what developers are used to doing with code via unit testing.
There’s another concept we can borrow from traditional development: creating dedicated test data that can be used over and over to maximize test outcomes. In this blog, we’ll explore how controlling the data that starts the flow helps you, the admin, add a significant level of control and predictability to your flow tests.
Of course, you can re-use data that’s already in the org. And in many cases, this will be sufficient, especially if you’re testing within an environment that mirrors your production data, like a full data sandbox. However, consider the following situations.
In these scenarios, instead of relying on the shape of a specific org’s data (in other words, the data that exists in the org where the test runs), what if you could replicate the same set of test data, tailored to your needs, for every flow test?
That’s where admins can borrow the concept of a dedicated suite of test data to test against. It puts you in control of the data you need and guarantees access despite where that data is being used.
There are a couple of key things to know about using dedicated test data. First, it’s generated by the system and not the user (in this case, Apex, but we’ll get to that next). Second, the data is ephemeral, meaning it only exists for the time required to run the test and is never actually written to the data layer.
This means you can create, update, and delete records to define your use cases without worrying about impacting any real data, and the data will work the same.
Note: If you have a flow test using org data instead of Apex test data, while it might rely on existing records, all changes are rolled back and do not impact your data layer. The difference is that the records need to exist to be able to run the tests.
Creating a proper invocable Apex method that will 1) work correctly in Flow and 2) not add unnecessary code into your org can be daunting, so it’s time to bring your developers to the table to get that test data set up and running.
What you need to bring to the data is an understanding of the data that you want to use to test, so that you can give that to the developer as required.
When discussing adding this functionality to your flow, ask yourself:
Equipped with your responses, you can convert these requirements for your test data into a request for developers. Your teams may have existing docs, workflows, or other request methods, but some fundamental things include:
Pro Tip: If you have access to an AI tool like Claude, ChatGPT, or Gemini, use it to organize these questions and get recommendations for format and additional information (like that the class must be global).
Once the class is created and deployed to your org, you can add it under the Test Setup tab of your flow test.
Using test data sets that create the data needed to run the test, rather than relying on data in the org, gives you a portable, predictable set of records that will behave exactly the same across different environments.
Another advantage of this is that once the Apex is created, these methods become a reusable set of classes that can be run over and over again. Using data generated specifically for the test, instead of relying on a set of transactions that ultimately gets rolled back, is a faster and more efficient way to execute your tests.
Finally, since the data is all based on code, if your needs change, the code can be updated rather than having to update your actual data layer to meet your needs. While this does require Apex, it’s similar to partnering with developers using invocable methods to execute edge cases where code can help finish the solution. Need more or less data? These can be small code changes in an artificial set of test data.
Start small, with simpler flows you can easily have a comprehensive feel for what kind of data is required. This will validate the approach of moving away from org data, and get the wheels moving when it comes to working with developers on the requirements for the code. It will also give developers a starting point to determine how best to meet future requests for flow test data.
As Salesforce Admins, we often build Screen Flows to capture answers. But some workflows need to capture something more nuanced: user intent. In these cases, we need to know not only what a user entered, but also whether they reviewed existing information, confirmed it was still accurate, or actively changed it. A standard editable field […]
You shipped an agent. It’s working — and now everyone wants a piece of it. “Can it also handle billing?” “What about account inquiries?” “Can it do onboarding too?” Before long, your focused agent is being asked to do everything at once, and that’s where things get messy. Multi-agent orchestration is how you fix that: […]
Every admin knows the rule: Test in a sandbox before it breaks in production. Or as the saying goes, measure twice and cut once. When new or updated solutions are released to your users, you want to be able to predict that they will have the experience you intend. This also goes for ensuring that […]
