If you opened Flow Builder recently and the Debug button was gone, nothing is broken. In Winter '27, Salesforce introduced Flow Test Mode (Beta): a separate testing view that takes the place of Debug once it is turned on. Debugging and automated testing now live in the same place.
It sounds like a small UI change, but it is the biggest step for flow testing in years. You can now save a debug run as a reusable test, fake the output of callouts and subflows, add expected results, and see which paths in your flow are covered. This post explains what Test Mode does, how to turn it on safely, and how to start using it without rebuilding your whole testing process.
Why the Debug button disappeared
Salesforce's view is that most "debugging" is really testing: you set up a record, run the flow, and check it did the right thing. So Test Mode replaces the Debug button on the toolbar with a Test option that opens a dedicated workspace. Building stays on the canvas; testing and troubleshooting move to their own view.
Test Mode is opt-in. It appears only after someone turns on the beta in your org (see below). If you did not turn it on and Debug is missing, check whether another admin did.
How to turn on Flow Test Mode
- From Setup, enter Process in Quick Find and select Process Automation Settings.
- Select Flow Test Mode (Beta) (the Salesforce Admins blog calls it Enable Flow Test Mode (Beta)) and save.
- Open a record-triggered or autolaunched flow and click Test. The canvas switches to a test view. To go back to building, click Build.
Test Mode is available in Lightning Experience in Professional, Enterprise, Performance, Unlimited and Developer editions. Like every Salesforce beta, it is covered by the Beta Services Terms rather than your normal service terms.
Before you turn it on anywhere that matters:
- Start in a sandbox. It is a beta, and it changes how every flow author in the org debugs. Try it with your team before switching it on in production.
- Know the supported flow types. In the beta, Test Mode covers record-triggered and autolaunched (no trigger) flows. Salesforce plans to add screen flows and scheduled flows later.
- Deployments need the beta on both sides. If you deploy a test to another org, the target org must have the beta enabled too. Turn it on in every org in your pipeline before you deploy flow tests.
What you can do in Test Mode
Save a debug run as a test scenario
With no saved scenarios, the test setup panel opens. Enter the inputs (the triggering record, variable values), click Run Scenario, then Save Scenario to keep it. Test Mode keeps the triggering record, input variables and any mocked outputs. Next time, you open the scenario and run it, or run several at once.
Two things to know: you can only make limited edits to the flow itself while in Test Mode, and if you switch scenarios or modes without saving, you lose your unsaved changes to that scenario.
That turns the throwaway debug session into something reusable. Build a small library per flow, such as "New high-priority case", "Existing closed case" and "Case with no account", and share it with the team.
Enter a record ID directly
You can now type a 15- or 18-character record ID in the test input panel. This helps with records that are hard to find by search, such as cases, campaign members, content documents and setup objects.
Fill in simple collections
Primitive collections, such as a text collection, can now be filled in directly when you test. Enter values as a semicolon-separated list or one by one, without editing the flow to hard-code them.
Mock subflows and actions
You can mock the output of a subflow or action, so the element returns a value you define instead of actually running. This is the feature many admins have wanted for years. If your flow makes an HTTP callout, you can give it a fake response and test the rest of the logic without calling the real system.
Add assertions and turn scenarios into regression tests
A saved scenario is a test without expected results. Select Scenario Testing Automation, then add assertions (for example "Status equals Escalated" or "Owner is the Tier 2 queue") and it becomes an automated test that passes or fails. Salesforce describes using Apex test classes to create isolated test data for those tests, so they do not depend on records that happen to exist in one sandbox.
See test coverage on the canvas
With automated tests in place, Test Mode can show how much of the flow your tests cover, and highlights the covered paths on the canvas. The paths that stay unhighlighted are your untested decisions.
Coverage only counts saved scenarios that have assertions, and failed tests do not count. A flow with ten saved scenarios but no assertions shows no coverage at all.
A simple way to start
You do not need to test every flow on day one. A practical order:
- Pick the flows that fail most. Start with the flows that cause real errors for real users, not the ones with the most runs. A flow failing 40% of 200 runs matters more than one failing twice in ten thousand.
- Save two or three scenarios per flow. One happy path, one edge case, and the case that caused the last bug.
- Mock anything external. Callouts and slow subflows make tests brittle. Mock them so the test checks your logic, not someone else's API.
- Add assertions to the scenarios that matter. Each assertion is one less thing someone has to check by hand before a release.
- Look at coverage last. Coverage is useful for finding forgotten branches. It is not a goal on its own.
What Test Mode does not do (yet)
- It is a beta. Behaviour and naming can still change, and beta features are not covered like generally available ones. Keep a note of which orgs have it switched on.
- Not every flow type is covered. Screen flows and scheduled flows are planned, not in the beta.
- Tests run before deployment, not in production. A passing test proves the logic works for the data you gave it. It does not tell you how the flow behaves against real users, real data and other automation in production.
- AI test generation is announced, not something to rely on. Salesforce has described Agentforce drafting test scenarios and test data for flows. Treat that as a roadmap until you see it working in your own org.
Testing before release, monitoring after
Test Mode covers the part before you ship. You still need to know what happens after. Flows that pass every test can still fail in production because of a validation rule someone added, a permission a user does not have, or data nobody thought of.
That is where orgadmin.ai fits in:
- Find the flows worth testing first. Flow Health reads your org's flow interview logs and shows a real failure rate per flow, which users hit the errors, and how failures trend over 30 days to a year. Sort by failure rate and you have your Test Mode backlog.
- Check a fix actually worked. After you deploy a fixed flow, Flow Health shows whether the failure rate drops, so you can tell a real fix from a lucky week.
- Dig into the failures tests did not catch. Debug Logs pulls the org's captured logs and has AI read up to five related ones together, pinpointing exceptions, the slowest SOQL and DML, and governor-limit use in the transaction your flow ran in.
- Ship with a validate step. Deployments lets you validate before you deploy. Remember to turn on the Test Mode beta in the target org first if your deployment includes flow tests.
Checklist
- Turn on Enable Flow Test Mode (Beta) in a sandbox and try it with the team
- Tell flow authors that Debug has moved into Test Mode
- Turn the beta on in every org your flow tests will be deployed to
- List your highest-failure flows and save two or three scenarios for each
- Mock callouts and subflows so tests check your logic only
- Add assertions to the scenarios that protect critical processes
- Watch failure rates after each release to confirm fixes held
Last checked 19 October 2026 against Salesforce's Winter '27 release note and the Admins blog post introducing Flow Test Mode (Beta). Beta features change between releases, so check the current release notes before you roll it out.