Flow Testing Finally Grew Up in Winter ’27

A few years ago, I inherited a record-triggered Flow that had been marked fully tested in a release tracker.

It was an Opportunity Flow that came with a handoff doc claiming full test coverage.

The proof was a screenshot of the Debug sidebar showing a green execution path on a single test record. The Flow itself had four decision branches, two subflows, and an invocable Apex action. Three days after it went to production, an inside sales rep with a restricted profile tried to update an account and threw an unhandled fault.

The Flow had never been tested. Someone had just watched it run once.

That pattern has been standard practice in Salesforce orgs for a long time. We build pricing engines, onboarding automation, entitlement logic, and ERP integrations in Flow Builder, but our validation process has remained manual and fragile.

Winter ’27 introduces a native Flow Test Mode in prerelease orgs that begins addressing this gap. It replaces manual debug runs with versioned test scenarios, assertions, mock responses, and visual coverage metrics.

The official release notes come out August 19, so specific limits and UI details may change before production. But the architecture in preview orgs is worth understanding now.

What Changes in Flow Builder

Enabling Flow Test Mode in Process Automation Settings splits Flow Builder into two workspaces: Build and Test.

Build mode handles the canvas, data elements, and routing logic without the old Debug button in the top bar. Test mode contains your testing suite.

Flow Builder
├── Build Mode: Canvas logic, data elements, and screen configuration
└── Test Mode: Saved scenarios, test data silos, mock outputs, and assertions

The core capabilities in the preview build include:

1. Versioned test scenarios. You configure inputs once and save them with the Flow version. When someone edits a formula or adds a decision path months later, you rerun the saved suite in seconds instead of re-entering test values manually.
2. Isolated test data. Tests can use dedicated data silos rather than depending on existing sandbox records that might get modified or deleted.
3. Mock outputs for invocable actions. If your Flow calls an external service or Apex action, you can define mock return values directly in the test scenario. This makes it straightforward to test error handling and empty responses without touching live endpoints.
4. Configurable assertions. You define explicit validation rules on field values, created records, or collection counts to confirm the business outcome, rather than scanning debug logs to see where the execution line went.
5. Path coverage. The canvas displays which elements and decision branches your scenarios covered, highlighting gaps in your test suite.

Why Reusable Scenarios Matter

The main benefit here is not the interface; it is the ability to run repeatable regression checks.

When test scenarios are saved directly in metadata:

• Peer reviews become practical. Reviewers can check the scenarios submitted with a user story to verify edge cases and failure paths.
• Shared subflows are safer to touch. Updating a core utility subflow no longer requires manual smoke tests across every parent Flow.
• Deployment gates become concrete. Teams can require all saved scenarios to pass before deploying a Flow version to staging or production.

One practical warning: path coverage is only a diagnostic tool. Traversing an element does not mean the output was correct. If a test scenario runs through every node but contains no assertions on the resulting record state, it does not prove the Flow works.

Adoption Plan for Release Prep

Do not try to backfill tests for every existing Flow. Focus on new work and high-risk automations first:

1. Target critical business paths. Prioritize automations handling revenue calculations, permission assignments, case escalation, or external syncs.
2. Build four scenarios per critical Flow. Include a standard happy path, a restricted-permission user test, an empty or null input payload, and an invocable action failure.
3. Set a team standard. Require every new Flow or major revision to include passing test scenarios before it moves to peer review.

Winter ’27 Release Calendar

• August 13, 2026: Prerelease orgs available.
• August 19, 2026: Official release notes published.
• August 27, 2026 (5:00 PM PT): Sandbox refresh cutoff for preview instances.
• August 28, 2026: Sandbox preview begins.
• September - October 2026: Production release weekends.