End-to-end flow testing, with Flow Test Mode (Beta) and TestZeus

A FLOW TESTING GUIDE FOR SALESFORCE TEAMS

Salesforce announced Flow Test Mode on September 29, 2026. It’s an opt-in beta, and it fixes a lot of what made testing inside Flow Builder painful. If you build flows, switch it on in a sandbox and try it.

There’s a catch the announcement doesn’t cover, though. A flow can pass every test in Flow Builder and still fail for the person who clicks Save.

That happens because Flow Builder tests the flow, while your users run the whole org. By the time their record saves, it has been through validation rules, other flows on the same object, Apex triggers, sharing and permissions, and maybe a callout to a system that’s having a bad day. Any of those can break the process while your flow’s logic stays perfectly correct.

We build test automation for Salesforce at TestZeus. The gap between “the flow works” and “the process works” is the reason we built flow testing into the product.

This guide is for everyone who has a hand in a flow before it ships: the admin who builds it, the developer whose Apex runs in the same transaction, the tester who owns regression, and the business analyst who wrote the requirement. We’ll cover what Test Mode gives you, where it stops, and how to test a flow end to end, from the first click to the last record it creates.

What Test Mode gives you

The Debug button is gone. Its replacement is a Test view that puts debugging and automated tests in one place, away from the canvas where you build. That separation makes sense, because building a flow and checking it are different jobs.

The feature most teams will use first is saved scenarios. Run a flow once, then save the setup as a named test, including the triggering record, the input variables and any mocked outputs. Your “new high-priority Case” run becomes one click, for you and for whoever picks up the flow next.

Add assertions to a saved scenario and it becomes a regression test. For now, isolated test data still comes from Apex test classes, so admins may need a developer for that piece.

Inputs are easier too. You can paste a 15- or 18-character record ID for objects that are hard to search, like Cases or Campaign Members, and fill text and other primitive collections without editing the flow.

Mocking lets you fake the output of a subflow or an action, HTTP callouts included, so the rest of the flow runs on its own. Salesforce has also said Winter ’27 will highlight path coverage on the canvas and bring Agentforce drafting test scenarios and generating isolated test data.

Our take: this is proper unit testing for flows, and it lives in the tool flow builders already use every day. Turn it on.

What a test inside Flow Builder can’t see

Test Mode answers one question, and answers it well: does this flow’s logic do what we designed?

The people who asked for the flow care about something else. Did the deal close, did the onboarding Case get created, and did the customer get the welcome email?

Here are five ways a flow can pass in Flow Builder and still let them down:

1. A validation rule blocks the record your flow creates. Say the flow creates a Contact, and last month someone added a rule that requires a phone number. Your test Account had a phone number, but plenty of real Accounts don’t.

2. The person running it isn’t an admin. You tested with full access. A sales rep launches a screen flow that runs in user context and can’t read an object it needs, or never sees the quick action because it isn’t on their page layout.

3. Other automation shares the transaction. Your Account flow creates a Contact, a second flow fires on Contact, and an Apex trigger updates the Account again. Salesforce has previewed Agentforce pulling that whole transaction together for troubleshooting, but it isn’t here yet, and your release might be on Friday.

4. The mock passes and the integration doesn’t. You mocked the ERP callout with clean JSON. In the real sandbox, the endpoint returns a 401 because a credential expired, and the mocked test keeps passing anyway.

5. A Salesforce release changes the org around your flow. There are three major releases a year, and your flow can stay exactly the same while the platform behavior it depends on shifts.

Screen flows, the ones users click through, also aren’t covered by the beta yet.

In every one of these cases the flow’s logic is fine. The process around it breaks, and you only catch that by testing the process.

Two layers of flow testing

Good flow testing has two layers. Test Mode checks the logic. An end-to-end test checks that the process works for the person doing it.

Test Mode looks at one box. A real user’s Save touches all of them.

Use Test Mode while you build, and run end-to-end tests before anything ships.

Who owns which layer

Flow quality usually involves more than one person, and the two layers map onto roles fairly cleanly.

Admins get the most out of Test Mode. Save a scenario for each decision outcome while the logic is still fresh in your head, and rerun them every time you change the flow.

Developers show up on both sides. Test Mode relies on Apex test classes for isolated data today, and your triggers run in the same transaction as the flow. An end-to-end run shows whether your code and the flow work together.

Testers own the end-to-end layer. That means a regression suite that walks through the UI the way users do and runs before every deploy and every Salesforce release.

Business analysts wrote the requirement the flow came from. A TestZeus test reads a lot like acceptance criteria, so when one fails, a BA can read it and say whether the flow or the requirement needs to change.

How to test a flow end to end in TestZeus

We built flow testing into TestZeus for this gap. You write the test in plain English, TestZeus runs it through the real Salesforce UI, and then it shows you what the flow did inside.

Here’s the example from our launch demo. The flow is simple: when a user creates an Account, create a Contact from its values. The test creates the Account the way a user would, then adds one line that tells TestZeus to trace the flow:

The third step does the tracing. It needs no flow IDs, no Apex and no setup screen.

Then run it and read the trace:

1. Click Live Test at the top right.

2. Open the run. You’ll find the usual run artifacts, with the flow-specific ones at the bottom.

3. Check the header. It shows the flow’s name, what triggered it (here, a record-triggered flow on Account, after save), when it started and how many elements ran.

4. Read the Flow Diagram. Your flow might have a dozen branches, but TestZeus draws only the route Salesforce actually took. In the demo that’s the flow start, Create Records and Interview Complete.

5. Open the Element Timeline to see every element in the order it ran.

6. Click any element. Click Create Records and the side panel shows its result, its timestamp and the values it changed, including the ID of the Contact it created.

The TestZeus trace for the demo flow. The diagram shows the path Salesforce ran, and the side panel shows what Create Records wrote.

That last step is the one you’ll appreciate late at night before a release. In a big flow, failures rarely come from the design itself. They usually come from a wrong value passed between two elements, and seeing the values at each step points you straight at it.

Because the test drives the real UI, everything else runs for real too: validation rules, page layouts and other automation. If any of them breaks the process, the test fails at the same point your user would.

Worked example: Closed Won starts onboarding

Most orgs have some version of this flow. When an Opportunity moves to Closed Won, a record-triggered flow creates an onboarding Case. Deals over $100K get High priority and everything else gets Normal. The Case goes to the Onboarding queue, and the customer gets a welcome email.

Here’s how we’d split the testing.

In Test Mode, test the logic. Save one scenario per branch and add assertions:

• “Closed Won, $150K” expects priority High.

• “Closed Won, $40K” expects priority Normal.

• “Closed Lost” expects no Case at all.

• “Already Closed Won, edited again” expects no duplicate Case.

Mock the email action at this layer, since you’re only checking the decision logic.

In TestZeus, test the process. Walk through it the way a sales rep would:

The stage change goes through the real UI, so required fields, validation rules and the sales path all run. The trace confirms the flow took the over-$100K branch and shows the values it used. The last three steps check what the business cares about.

If your BA wrote acceptance criteria for this flow, put them next to the test above. They should say nearly the same thing.

Test Mode tells you a $150K deal gets High priority. TestZeus tells you the rep could close the deal, the onboarding team got the Case, and the customer got the email.

A Pre-release checklist for flows

Run through this before any flow ships. Test Mode covers the first five items, and end-to-end tests cover the rest.

• Every decision outcome has a saved scenario with an assertion.

• You tested a record that should not trigger the flow, because entry conditions fail quietly.

• If the flow runs on both create and update, you tested both.

• Every field the flow reads was tested blank at least once.

• Fault paths go somewhere useful, and you forced at least one to fire.

• There’s an end-to-end run for each real persona, including users with the least access.

• The end-to-end run checks what the flow creates and any automation those records trigger.

• Callouts hit the real sandbox endpoint at least once, with mocks used everywhere else.

• The end-to-end suite runs before every deploy and in your release preview sandbox.

Test the flow, then test the business

Salesforce says Flow now runs more than 690 billion times a month. In a lot of orgs it carries the processes that bring in and keep revenue, like quoting, onboarding, renewals and case routing.

Test Mode is Salesforce acknowledging that flows need the same test discipline as code, with unit tests close to the build and end-to-end tests close to the user. It makes the first half easier, even in beta. We built TestZeus flow testing so the second half is something your whole team can write and read.

A passing flow test proves the logic. Ship when the process passes too.

TRY IT Bring us your messiest flow. Try flow testing at testzeus.com. Write the test in plain English, run it through the real UI and read the trace. The messier the flow, the more the trace will show you.

Sources:- Flow Test Mode (Beta): The Future of Flow Testing, Salesforce Admins blog, September 29, 2026.