Flows in Winter’27: Flows Finally Get Proper Testing and Change Tracking

Salesforce Flow testing gets its biggest upgrade in years with Winter ’27. A new Test Mode, currently in beta, puts debugging and repeatable tests in one place inside Flow Builder. Updated version comparison and a new edit history panel also make it easier to see what changed.

Here’s what Salesforce Winter ’27 Flows now offer for testing, what’s still in beta, and how to put it to work. You’ll also find a simple example you can copy for your own record-triggered flows.

What Test Mode Changes in Flow Builder

Winter ’27 splits Flow Builder into Build and Test views. The Debug button is gone, and Test Mode takes its place.

Saved Scenarios: The debug scenario can be saved together with its parent record, inputs, and mocked outputs. Any user in the project will have access to it and can execute the test in one click.
Mocked Outputs: It is possible to mock an output of a subflow or action such as HTTP Callouts and test other parts of the flow separately.
Easier Inputs: It is easy to use a static 15 or 18-character record Id and populate basic collections such as text collection.
Coverage View: The Test mode gives information about the coverage of the flow in terms of test execution.

How to turn it on

Test Mode is opt-in. In Setup, open Process Automation Settings and check Enable Flow Test Mode (Beta). According to Salesforce Admins’ Test Mode announcement, the beta covers record-triggered and auto launched flows. Support for screen flows and scheduled flows is planned, not available yet.

If you deploy a test to another org, that org needs the beta enabled too.

From a Debug Run to a Regression Test

Saved debug runs are described as automated tests that lack expected outcomes by Salesforce. Once you have included the expected results, known as assertions, then it will become a regression test.

Manual scenario: you run it and judge the result yourself.
Scenario with assertions: the test passes or fails on its own, so it can guard the flow against future edits.
Isolated test data: Salesforce says Apex test classes can create separate data for each test, so results don’t depend on live records.

Once tests with assertions exist, the coverage view shows which paths they reach. A dark path means nobody has proven it works.

What to keep in mind during the beta

Test Mode should be run in the sandbox while continuing the existing testing process. It is also advisable to verify Salesforce’s documentation regarding whether the Test Mode coverage counts towards your deployment coverage needs.

Salesforce has also provided AI drafted test scenarios for Winter ‘27. Check their availability in your organisation before you finally implement it.

Seeing What Changed Between Flow Versions

Testing tells you whether a flow works. Version tools tell you what changed. That’s why Salesforce Flow change tracking in Winter ’27 matters to reviewers, not just builders.

Comparison results you can click through. Each change between two versions now opens more detail, as covered in Salesforce’s release note on comparing Flow versions. The separate Change Details column has been removed to cut clutter.
Edit history panel. It shows a timeline of each save, lets you drill into individual element changes, and lets you restore an earlier point.

A reviewer can open the comparison, read each change, then confirm the saved scenarios still pass. Of the features covered here, only Test Mode carries a beta label in Salesforce’s Winter ’27 material. Rollout can vary by org, so check your sandbox.

A Record-Triggered Example: Closed Won Handoff

Let us assume there is a flow that triggers whenever the stage changes to closed won on Opportunity. There will be four scenarios:

Amount greater than 50,000 – Create a kick-off task for a senior owner.
Amount less than 50,000 – Create an onboarding task.
Any other change in stage – No action.
No owner or bad data – Fault path logs the error.

Before activation, an admin can:

Save only one scenario per path, for example: “Closed Won, large deal.”
Define boundary scenarios on 50,000 and 49,999.
Mock the response from an external action that generates a notification so that no real call is made.
Define assertions for the task owner, priority, and due date.
Go to the coverage window and add a scenario to cover the dark paths.

When the threshold changes next quarter, rerun every scenario, then compare versions before approving the change.

Which Testing Tool Answers Which Question

Testing approach	What it helps validate	When to use it
Manual test scenario	Logic works for one saved setup	While building, or reproducing a reported error
Automated test with assertions	Results match expected outcomes	Critical flows that change often
Mocked outputs	Flow logic without calling actions or subflows	Callouts and unavailable dependencies
Test coverage	Which paths your tests reach	Before a deployment review
Version comparison and edit history	What changed, and when	Approvals, handovers, rollback decisions

A Testing Routine for Production-Safe Automation

Move past the sunny-day scenario – Test all potential outcomes of the decision, not just the one that you created.
Input weird values – Null fields, zeros, large text entries, and threshold boundaries will expose more flaws than normal input.
Consciously test your fault paths – Enter an invalid record and verify that your fault path is functioning.
Enter safe values only – Only use sandbox records and test data, not actual customer records.
Check permissions – A flow that works for an admin may fail for others. Winter ’27 adds a run context option that enforces the running user’s permissions, so test with that in mind.
Compare before approving – Review version changes for any significant edit.
Keep regression tests for critical flows – Rerun them after every change.

However, Winter ’27 also alerts you to save time from missing required fields and field length restrictions. This makes some usual mistakes easy to get rid of before testing, and Salesforce Flow debugging becomes faster due to one-click access to scenarios.

Treat Salesforce Flow testing as part of Flow maintenance, not a last step before go-live.

Where Experienced Salesforce Help Pays Off

Those that have a lot of accumulated automation experience in years will have flows that no one remembers anymore. An implementation partner is someone who will help you to test Salesforce Flows in Winter ’27:

Auditing critical flows and deciding where Salesforce Flow testing should start.
Building shared scenario libraries and assertions that admins and developers both trust.
Testing integrations. Mocked outputs help with isolation, but sandbox runs against real systems still matter, and Salesforce integration services can cover that work.
Setting review habits and governance for Flow changes.
Planning a safe sandbox evaluation of the beta.

For complex implementations, experienced Salesforce consulting keeps this work structured instead of ad hoc.

Conclusion

Winter ’27 gives teams a practical way to prove a flow works and see how it changed. Salesforce Flow testing now lives where you build, and better Salesforce Flow change tracking makes reviews less of a guessing game.

The takeaway: reliable automation needs tests and controlled change. This week, enable Test Mode in a sandbox, save a scenario for each path in your three most important flows, add assertions, and compare versions before the next approval. If your automation is complex or tied to other systems, bring in experienced guidance early.

FAQs

Is Test Mode production-ready?

It is still a beta release, so evaluate it in the sandbox first. In Test Mode, the Salesforce Flow testing capability currently includes record-triggered and auto launched flows.

Is Flow version comparison possible in Winter ’27?

Yes. The comparison capability was available previously, but now Winter ’27 provides a click-through capability for details of each difference. The edit history provides a timeline per save.

What is an assertion in a Flow test?

An assertion is a condition that must be satisfied, like “the kickoff task exists and has the correct owner.” The test passes only if the assertion holds true.

Can I test a flow without connecting to external systems?

Yes. Mock the output from the action or subflow, and the flow continues running based on the mocked response. Nevertheless, perform the sandbox test against the real-world system.

Does every org need to have Test Mode enabled?

Yes. It is an opt-in capability for every org, and a target org will need the beta release enabled to receive the tests that you deploy.

Why test more than one scenario?

A flow having multiple decision states will have multiple paths, and a single successful path proves just one of those paths. Each path should be tested separately for boundary values.

What do I test first?

Test flows affecting money, customer communications, and/or external systems integration first. These are the most expensive flows to break.

For more insights, updates, and expert tips, follow us on LinkedIn.