Why Flow Tests Exist
For years, testing a flow meant one of two things: running Debug mode by hand, or writing Apex test classes that executed the flow via Flow.Interview.createInterview(). Both worked. Neither scaled.
Flow Test is a native capability that lets you write test cases directly against a flow, assert expected behavior, and run them as a suite. Tests live next to the flow, version with it, and run via CI like any other metadata.
If your org still relies on Debug-by-hand for flow QA, you are one bad deploy away from production pain.
The Shape of a Flow Test
Each test consists of:
- Trigger — the record state that launches the flow (for record-triggered flows) or input parameters (for autolaunched/screen flows).
- Initial state — any pre-existing records the flow will read.
- Path — the expected sequence of elements the flow should execute.
- Assertions — the expected final state: record fields, collection values, output variables.
Tests are saved with the flow and run via the Flow Test panel or via CLI.
Writing Your First Test
Open any flow. Click View Tests → New Test. You’ll see a form with the trigger (pre-populated based on flow type) and slots for assertions.
For a record-triggered flow that sets Case Priority based on Account Tier:
- Test name:
Sets_Priority_High_For_Enterprise_Accounts - Trigger record: a Case with AccountId pointing to an Enterprise-tier Account.
- Initial state: the Account record with Tier = ‘Enterprise’.
- Assertion: after flow execution, the Case record’s Priority field equals ‘High’.
Save and run. The test executes the flow with your inputs, records the path, and validates the assertion.
What to Test
Cover the cases that matter:
Happy paths. For each major branch in your flow, one test that exercises the full happy path and validates the final state.
Edge cases. Null inputs, boundary values (zero-length collections, max field lengths), missing related records.
Failure modes. When a validation rule blocks a DML, does your fault path run correctly? Test it.
Permission variations. If flow behavior differs by user profile, test with multiple users. Test-as-user is supported.
Assertions You Can Make
Flow Test assertions cover:
- Field values on records.
Case.Priority = 'High'. - Record existence. A new Task was created with a specific subject.
- Record non-existence. No Opportunity was updated.
- Element execution. A specific Decision outcome was taken.
- Output variables. For autolaunched flows, the result output matches expected.
- Fault path taken. The flow errored out through the expected fault path, not silently.
Assertion chains let you verify multiple things per test. Keep each test focused — a test that asserts twelve things tells you “something is wrong” but not “what.”
Running Tests
Tests run in three places:
In the UI. Open the flow, View Tests, run one or all. Results show pass/fail with a trace of the execution.
Via the CLI. sf flow test run --target-org MyOrg --flow MyFlow runs all tests on that flow. Add --json to integrate with CI.
In CI. Deploy flows to a scratch org or sandbox, run flow tests, fail the pipeline on test failures. Wire into any CI provider — GitHub Actions, GitLab CI, Azure DevOps, Jenkins.
Test Coverage Expectations
Salesforce does not currently require a coverage threshold for flow tests the way it does for Apex (75%). That will likely change. Plan ahead:
- Write tests for every new flow before deploying.
- Backfill tests for existing production-critical flows.
- Target at least one test per Decision branch as a minimum.
Anti-Patterns
Testing everything through one gigantic test. One test per scenario. Small, focused assertions.
Tests that depend on org data. Tests should set up their own records, not rely on data already in the org. Portability suffers otherwise.
Tests that test implementation, not behavior. Assert on outcomes (record field X equals Y), not on internal steps (element 7 was executed). Implementation changes; behavior shouldn’t.
Skipping negative assertions. “This test proves the flow does X.” Add assertions proving it doesn’t also do Y, Z unexpectedly.
CI Integration Pattern
A typical pipeline for flow-heavy orgs:
- Developer commits flow metadata to Git.
- CI deploys to a scratch org.
- CI runs Apex tests and Flow tests.
- CI returns results to the PR with pass/fail.
- PR merges only when both suites pass.
- Release deploys to staging; same tests re-run.
- Production deploy uses quick-deploy on validated tests.
This is standard practice for code. It now applies to Flow metadata too.
What Flow Test Doesn’t Cover
Screen flows with complex UI interactions are partially covered. Automation tests (visual, user-in-the-loop) still require Playwright, Selenium, or Salesforce’s UI Test Automation Model (UTAM).
External service callouts can be mocked, but the mocking story is still maturing. Sophisticated orgs often complement Flow Tests with Apex test classes that provide richer mocking.
Migration Advice
If you’re adopting Flow Test in a mature org:
- Start with flows that break the most. Fix them once, write the test, move on.
- Write tests as part of every new flow — non-negotiable.
- For legacy flows, prioritize by blast radius. A flow on Case, Opportunity, or Account hits more downstream than one on a custom object.
- Budget a full sprint for catching up the critical 20% of your flows.
Frequently Asked Questions
Do Flow Tests count toward Apex test limits?
No. They run in their own context. The governor limits apply per test execution but they’re independent of Apex test limits.
Can I parameterize a test?
Each test has fixed inputs. For parameterized coverage, create multiple tests with different input sets, often named with the scenario suffix.
Do Flow Tests work on screen flows?
Partially. Screen inputs can be supplied programmatically; interactive screen components (like file upload) have limited test support today.
Are tests required for deployment?
Not yet universally. Individual orgs can enforce via deployment configs. Plan for this to become standard.