Platform
Winter '27 Flow Builder: Test Mode, multi-record screen flows, and the user-context switch
Seventeen Flow features land with Winter '27 and three of them change how you work: a test mode that saves and replays tests, screen flows that run against a whole list view, and a run option that enforces the user's permissions no matter who triggered the flow. This is what each does, which are beta, and the two things to do before your production weekend.
Most production orgs upgrade to Winter ‘27 on October 2 or October 9. Salesforce Ben’s Tim Combridge counted 17 new Flow features in the release, which is a lot of release notes for one builder.
Three of the seventeen change how an automation team works. The rest are quality of life, and some of them are the small things people have wanted for years. I will take the three first, then the rest in the order I would care about them, then the two pieces of work I would finish before the upgrade weekend. Anything in the wider Winter ‘27 post that touches Flow, such as the user-permission tightening, is referenced rather than repeated.
Flow Test Mode replaces debug, and saves what you did
The first big one is in beta. Flow Test Mode puts debugging and testing in one interface and lets you save a test and run it again. Until now, debugging a flow meant re-entering the same inputs every time you changed something, and the older test feature lived in a separate place with its own limits.
The practical change is repeatability. A saved test is a record of the inputs and the expected path. When someone edits the flow in six months, the test still exists, and running it tells them whether they broke the thing it was written to protect.
Two caveats. Beta means the feature can change under you, and it may not cover every flow type on day one. And a saved test only protects what it tests. The discipline is the same as it is for Apex: write the tests for the paths that would cost money if they broke, not for the ones that are easy to test.
Screen flows now run against a whole list
The second big one closes a gap that has produced a thousand workarounds. A screen flow launched from a quick action on a list view or a related list now receives the selected records as a text collection called ids, so one flow can process many records instead of one at a time.
If you have ever built a “select records, then click a button” experience with a custom LWC or a Visualforce page because a screen flow could only take one record, this is the feature that retires it.
The design note is the one you would expect. Inside the flow, treat the collection as a collection. A loop that does a Get Records and an Update Records per item will meet the governor limits the moment a user selects two hundred rows. Collect, then act once.
The user-context switch
The third is a run option with a long name: User Context, Enforces User Permissions. Set it and the flow can only touch data the running user could touch themselves, regardless of how the flow was launched.
The reason it matters now is the direction of the whole release. Winter ‘27 enforces profile filtering and moves several setup permissions behind dedicated grants, all covered in the Winter ‘27 post. Flows that run in system context because a builder never thought about it are the automation equivalent of an over-broad profile, and an agent calling that flow as an action inherits the gap.
The audit I would run before the upgrade weekend is short. List every flow, note its run mode, and for each one running in system context ask whether that was a decision. Where it was not, the new option is the fix. Where it was, write the reason down next to the flow so the next admin does not undo it.
Two save-time checks that stop bad deployments
Flow Builder now warns when a Create Records element leaves a required field unassigned, and when a value you assign is longer than the field allows. Both used to fail at runtime, in production, for a user, with an error message that named the flow and not the field.
Neither is exciting and both will save someone a weekend. They are also the kind of check that a drafted flow needs, because a fast confident draft is exactly where a required field gets missed.
The organisation features
Four features address the same problem: a flow that has grown for three years is hard to read.
Element grouping lets you highlight a section of the canvas, give it a label and a description, and collapse it. A flow with a dozen decisions becomes four named blocks.
Flow tags let you classify flows into categories you define, so the list view of two hundred flows can be filtered by what they are for. The unused resources filter finds variables that nothing references and resources with no description. And edit history gives a timeline of saves with the ability to restore a version and see what changed at the element level.
Together they make technical debt in Flow visible in the builder rather than in a spreadsheet. If your org has flows nobody dares open, grouping and tagging them is a reasonable first week after the upgrade.
The developer-facing details
Two features are for anyone who manages Flow metadata outside the builder. End elements are now saved to the flow XML, so an external editor or a version-control diff no longer loses their placement. Flow version comparison results are clickable, with the old Change Details column removed. Both matter more than they sound if you run flows through a pipeline alongside Apex.
Keyboard shortcuts arrive for moving around the canvas, including standard copy and paste. Conditional visibility rules now evaluate correctly when a formula references a component on the current screen, which was a long-standing trap. Quick-action window size for a screen flow modal is now configurable. And the builder moves to the Cosmos theme, which is cosmetic until you have to re-record every training video.
The Marketing Cloud pair
Two of the seventeen are specific to Marketing Cloud. Order events, such as returns, shipments and status changes, can trigger flows through the REST API in around three seconds instead of the seven to ten minutes the previous path took. And an audience flow can be copied without disrupting a live campaign, with control over which emails, messages and segments are cloned.
If you run commerce automation through Marketing Cloud, the first of those is a change in what “real time” means for a post-purchase journey.
What is beta and what is not
Of the seventeen, Flow Test Mode is the beta. Everything else Salesforce Ben lists is generally available with the release. That makes the test mode the one to trial in a sandbox and everything else safe to rely on the Monday after your upgrade.
One thing not in the release, in case you read it elsewhere: I found no Time screen component in the published list. If you have seen one mentioned, check the release notes before planning around it.
Two things to do before the production weekend
Write tests for the flows that would cost money. Pick the five record-triggered or screen flows that touch revenue, entitlements or customer communication, and build a saved test for each in a preview sandbox. You are testing the feature and protecting the flow in the same hour.
Run the user-context audit. Every flow in system context is either a decision or an accident. Make the accidents into decisions before profile filtering and the Winter ‘27 permission changes surface them for you.
If you want a view of which flows are riskiest, the org health scorecard flags automation running with elevated context alongside the other exposure on the release list.
Understanding the basics
What is Flow Test Mode in Salesforce?
A Winter ‘27 beta feature that combines debugging and testing in one Flow Builder interface and lets you save a test and run it again later. It replaces the legacy debug experience and is meant to make flow tests repeatable across edits.
How do I run a screen flow on multiple records at once?
In Winter ‘27, launch the screen flow from a quick action on a list view or a related list. The selected records arrive in the flow as a text collection named ids, which you process as a collection rather than one record at a time.
What does the Enforces User Permissions run option do?
It restricts a flow to the data access of the running user regardless of how the flow was launched, so a flow cannot read or change records the user could not touch themselves. It is generally available with Winter ‘27.
Which Winter ‘27 Flow features are generally available?
Everything on Salesforce Ben’s list of seventeen except Flow Test Mode, which is in beta. The generally available items include flow tags, multi-record screen flows, save-time validation, the user-context option, element grouping, edit history, keyboard shortcuts and the Cosmos theme.
The builder is catching up with the code
Every one of the three big features is something Apex developers have had for years: repeatable tests, bulk processing, and running with the user’s permissions. Flow was always the tool that let you skip those disciplines, and Winter ‘27 is the release where the builder starts to expect them.
That is good news for admins who already worked that way and a reasonable nudge for the ones who did not. Write the five tests, run the audit, and the upgrade weekend is a non-event.
If you want the flows that touch money tested and the system-context audit run before October 2, talk to us, or start with the automation savings calculator to see which flows earn the attention.
