Salesforce Winter ’27 introduces several improvements to Flow Builder. Some will make an administrator’s job easier. Others deserve a closer look before they’re introduced into an environment that already has years of automation running behind the scenes.

If you’ve worked with Salesforce long enough, you’ve probably encountered a Flow that nobody wants to touch.

It might be responsible for assigning leads, updating opportunities, or routing customer cases. It works most of the time, but nobody is entirely sure what will happen if someone changes it.

Maybe the administrator who built it has left the company. Maybe it has been modified several times by different consulting partners. Or perhaps it was originally intended to handle one straightforward process and has gradually taken on several others.

Whatever the reason, changing it feels risky.

This is one of the reasons I find the Flow updates in Salesforce Winter ’27 interesting. They address some of the everyday frustrations that come with maintaining Salesforce, particularly in organizations where automation has grown alongside the business.

Salesforce has improved how administrators test Flows, compare versions, identify certain errors, and control permissions. There are also changes to bulk processing and approvals that could make life easier for users.

But I wouldn’t rush to enable everything.

Winter ’27 has already reached production environments, and the more useful question now is what administrators should test before adopting these capabilities or deploying updated automation.

1. Flow Test Mode: Finally, a Better Way to Repeat the Same Test

One of the less enjoyable parts of maintaining Salesforce is reproducing a problem.

Someone reports that a lead was assigned incorrectly. You find the record, open the Flow, run the debugger, and try to work out which condition produced the unexpected result.

You make a change, then run through the same scenario again.

And again.

If the Flow has several decision elements, you might need to repeat the process with different records before you’re comfortable that the change hasn’t affected something else.

Salesforce Winter ’27 introduces Flow Test Mode, currently in beta, which brings debugging and testing into a dedicated area of Flow Builder.

For record-triggered and autolaunched flows, administrators can save test scenarios rather than entering the same information every time. The feature also supports expected-result assertions and provides visibility into which paths have been covered by tests.

That’s useful, especially when multiple people maintain the same automation.

Imagine a lead assignment Flow that sends prospects to different teams based on location, company size, and product interest.

The normal scenario is easy enough to test. A lead from New York with the correct information goes to the expected sales team.

But what happens when the location is missing? What if the prospect is already associated with an existing account? What if two assignment conditions apply?

Those are the situations I’d want to save and reuse.

The real benefit isn’t that testing becomes faster, although that’s certainly welcome. It’s that administrators can start building a record of what the Flow is supposed to do.

That becomes valuable six months later when somebody asks for a seemingly minor change.

Because Test Mode is still in beta, I would try it in a sandbox before making it part of the team’s standard deployment process. Salesforce has outlined the current functionality in its Flow Test Mode announcement.

2. Enforced User Permissions: The Change I’d Be Most Careful With

Of all the Winter ’27 Flow updates, this is one I’d pay particular attention to.

Salesforce has introduced a new execution option called User Context—Enforces User Permissions for screen flows and autolaunched flows using API version 68.0 or later.

The important distinction is how the Flow behaves when another automation calls it.

Previously, a Flow configured to run in user context could inherit elevated permissions from a calling Flow or Apex process operating in system context.

The new option allows administrators to enforce the running user’s permissions regardless of how the Flow is invoked.

That sounds like a relatively small technical change. In practice, it raises some important questions about how existing automation was designed.

Let’s say a sales representative uses a screen flow to update customer information. Behind that screen, another Flow performs additional updates.

The representative may not have direct permission to edit every field involved in the process. Perhaps the automation was deliberately designed to handle those updates on the user’s behalf.

If someone changes the execution context without understanding that arrangement, the process could stop working.

On the other hand, a Flow that inherits more access than intended may create a security concern.

Neither situation is something I’d want to discover after deployment.

I’d start by looking at Flows that call other Flows, particularly those involving sensitive customer information or records shared across departments.

Then I’d test them using the permissions of the people who actually use the process.

An administrator account is rarely a good substitute for this kind of testing. Administrators typically have access that ordinary sales, service, and customer success users don’t.

The goal should be to confirm that the Flow has the access it needs, without granting more than the process requires.

I also wouldn’t change every Flow to the new option just because it’s available. Understand the existing design first, then decide whether the new execution context is appropriate.

3. Screen Flows From List Views: Convenient Until Someone Selects the Wrong Records

I can see this becoming one of the more popular Winter ’27 enhancements.

Administrators can now configure screen flows that users launch from list views and related lists, allowing them to process multiple selected records.

For teams that regularly perform the same action across several records, this could remove a fair amount of repetitive work.

Think about a sales operations manager who needs to reassign leads after a territory change.

Instead of opening each lead individually, the manager can select a group of records and initiate the appropriate Flow.

That’s a better experience, provided the automation knows what to do with the selection.

The part I’d be concerned about is what happens when the records aren’t as consistent as expected.

Suppose the manager selects 40 leads. Most are eligible for reassignment, but several belong to active opportunities or accounts managed by another team.

Should those records be excluded? Should the Flow stop and explain the issue? Or should it allow the manager to proceed with a warning?

There’s no universal answer. It depends on the organization’s sales process.

This is where administrators need input from the people who own that process.

I’d also test what happens when users select records they cannot edit, when some records fail validation, and when the selection triggers additional automation.

A Flow that works perfectly on one record may behave differently when it updates dozens.

Bulk processing is a useful capability, but it also means one mistake can affect more records at once.

4. Better Error Warnings: Useful, but Don’t Trust Them Too Much

Winter ’27 adds more warnings inside Flow Builder, including checks for certain missing required fields and text values that may exceed field-length limits.

This is the sort of improvement that probably won’t attract much attention outside the Salesforce administrator community.

Still, it could save time.

Consider a Flow that creates an onboarding record after an opportunity moves to Closed Won.

During testing, everything works because the sample opportunity contains the expected information.

Then a sales representative closes an opportunity where one of those fields is blank.

The Flow fails, the onboarding record isn’t created, and customer success doesn’t receive the information it needs.

Better warnings may help catch some of these problems earlier.

The catch is that Salesforce can’t predict every value a Flow will receive.

Information might come from another Flow, an integration, or a field populated earlier in the process. A warning that works for a straightforward assignment may not catch a problem involving dynamic data.

So while I welcome the improvement, I wouldn’t change how I think about testing.

A Flow passing validation doesn’t necessarily mean the business process works.

I’d still want to see what happens with incomplete records, unusual field values, and situations that don’t follow the expected path.

And I’d ask the business users which exceptions they encounter most often.

They usually know where the process gets messy.

5. Automatic Retries for Record Locks: Helpful, but Why Are the Records Being Locked?

Record-locking errors can be frustrating because they’re not always easy to reproduce.

You might have a Flow that works correctly for weeks, then suddenly fails because another transaction is updating the same record.

Salesforce Winter ’27 introduces automatic retry behavior for certain record-lock errors during Flow transaction initialization, with a wait before another attempt.

That’s a useful improvement.

But I wouldn’t consider it a reason to ignore recurring locking problems.

Imagine an opportunity that gets updated by a sales representative, an integration, and several Flows.

One process changes the opportunity stage. Another updates related financial information. A third updates fields based on activity elsewhere in Salesforce.

If those processes regularly compete for the same records, automatic retries may help some transactions succeed. They don’t necessarily make the underlying design any simpler.

I’d be particularly interested in organizations where record-locking errors have become accepted as a normal part of working in Salesforce.

If the team regularly retries failed operations or manually corrects records afterward, that’s worth investigating.

Sometimes the problem is transaction timing. Sometimes it’s overlapping automation. And sometimes the organization has accumulated several processes that no longer need to exist separately.

Winter ’27 may make some of those failures less frequent, but I’d still want to understand what’s causing them.

6. Flow Version Comparison: A Small Improvement With Real Value for Older Salesforce Orgs

If you’ve inherited a Salesforce environment from another administrator or consulting partner, you know that documentation doesn’t always tell the full story.

You open a Flow and find conditions that don’t seem to make sense.

Maybe there’s a branch for a particular account type. Perhaps a field gets updated twice. Or there’s a subflow whose purpose isn’t immediately obvious.

You could remove the logic, but there’s always the possibility that it exists because of an exception nobody remembers.

This is where the Winter ’27 improvements to Flow Version Comparison and Edit History become useful.

Salesforce has made it easier to inspect differences between versions and review changes made to supported Flows.

For teams managing a large number of automations, that can make troubleshooting considerably easier.

Suppose an opportunity Flow starts behaving differently after a deployment.

Instead of manually examining two versions and trying to remember what changed, an administrator can review the differences and narrow down the investigation.

It won’t necessarily explain why someone made a particular decision, but it gives the team a better starting point.

I’d use this feature for more than troubleshooting.

If an organization is already planning to simplify its Salesforce environment, version history can help identify where automation has become more complicated over time.

A Flow that has been revised repeatedly may still be perfectly appropriate. But if every new business requirement has resulted in another condition or workaround, it may be worth reviewing the process itself.

We’ve discussed similar issues in our article on seven signs your Salesforce org needs a health check.

Sometimes the difficulty isn’t that Salesforce lacks functionality. It’s that the organization has lost track of how its existing functionality fits together.

7. Flow Approval Updates: The User Experience Matters More Than It Seems

Approval processes are easy to underestimate.

From a technical perspective, a discount approval might be straightforward. A request meets a threshold, goes to the appropriate person, and receives a decision.

But anyone who has worked with sales teams knows that the process rarely feels that simple to the people using it.

The representative doesn’t know which approval to request. The manager wants additional information. Finance needs to review an exception. Someone is out of office.

Eventually, the customer asks why the proposal is taking so long.

Winter ’27 includes several improvements to Flow Approval Processes.

The Request Approvals component can now present multiple approval processes on a record page, giving users a clearer way to initiate the appropriate request.

Salesforce has also introduced more flexibility around comments and approver selection, along with changes to how pending work items are presented.

Certain background steps can also run synchronously when the approval process uses the required API version.

I like the direction of these changes, but I think administrators should pay as much attention to the user experience as the configuration.

Take a sales organization with different approval requirements for standard discounts, nonstandard payment terms, and contract exceptions.

If a representative sees several approval options, will they know which one to select?

If they choose the wrong process, what happens next?

And if the approver rejects the request, does the representative know what needs to change before resubmitting it?

These aren’t particularly complicated questions, but they make a difference to how well the process works.

I’d also check what happens when an approver is unavailable, when a request is recalled, and when multiple approvals are required for the same deal.

An approval process should be easy to follow without compromising the controls that finance, legal, and sales leadership need.

Speed matters, but consistency matters just as much.

What I’d Actually Prioritize Before the Next Deployment

I wouldn’t spend the same amount of time testing every Winter ’27 feature.

My first priority would be anything that affects permissions or changes how an existing Flow executes. Those changes have the potential to interrupt processes that employees already depend on.

Next, I’d look at automation that handles multiple records or interacts with other systems. Bulk updates and integrations can create problems that are harder to identify through basic testing.

I’d also pay attention to approval processes, particularly where a delay could affect an active deal or customer commitment.

Flow Test Mode and version comparison are worth exploring because they can make the administrator’s job easier over time. But I wouldn’t introduce a new testing feature and assume that the organization’s release process is suddenly more reliable.

That still depends on what the team chooses to test.

A good example is lead assignment.

An administrator might confirm that the Flow runs successfully and updates the owner field. From a technical standpoint, the test passes.

But what if the lead goes to the wrong sales team?

The automation worked. The business process didn’t.

That’s why I think Salesforce testing needs to involve the people responsible for the outcome, not just the people responsible for the configuration.

Sales managers should help validate lead routing. Finance should review approval behavior. Customer success should confirm that onboarding automation provides the information needed after a deal closes.

The administrator doesn’t have to own every business decision.

In fact, one of the problems we see in growing Salesforce environments is that technical teams gradually become responsible for processes that should have clear business owners.

That arrangement works until something changes and nobody can agree on what the automation is supposed to do.

Winter ’27 Is Also a Good Time to Revisit Existing Automation

There’s a tendency to treat every Salesforce release as an opportunity to introduce more functionality.

Sometimes that’s appropriate.

But for organizations with mature Salesforce environments, I’d argue that reviewing existing automation can be just as valuable.

A company might have several Flows updating the same opportunity fields. Another might still rely on automation built around a sales process that changed two years ago.

The business has moved on, but the Salesforce configuration hasn’t.

That creates unnecessary complexity.

It also makes future changes harder because administrators have to consider dependencies that may no longer serve a useful purpose.

This becomes especially relevant as organizations explore Agentforce and other AI capabilities.

Before introducing more sophisticated automation, it’s worth understanding the processes already running in the background.

If lead ownership is inconsistent, customer information is incomplete, or approval responsibilities are unclear, AI won’t automatically correct those problems.

It may simply give the organization another way to encounter them.

Not every workflow needs an AI agent, either.

If a discount above a certain threshold always requires finance approval, a conventional Salesforce Flow may be the most appropriate solution.

There’s little value in introducing more complexity when a straightforward rule already addresses the business requirement.

The same principle applies to Winter ’27.

Use the features that solve an actual problem. Don’t introduce them simply because they’re new.

For a broader look at the release, our article on Salesforce Winter ’27 updates RevOps leaders should pay attention to covers changes beyond Flow Builder.

Final Thoughts: The Best Salesforce Automation Is the Kind You Can Maintain

What I appreciate about the Winter ’27 Flow updates is that several of them address the less visible work involved in managing Salesforce.

Testing an existing Flow isn’t particularly exciting. Neither is reviewing permissions, comparing versions, or investigating why two automations are trying to update the same record.

But these are the things that determine whether Salesforce remains manageable as an organization grows.

The new capabilities should help administrators spend less time recreating tests, investigating changes, and dealing with avoidable configuration errors.

That’s worth paying attention to.

At the same time, I’d be careful about treating every new feature as something that needs to be adopted immediately.

If an existing process works well, has clear ownership, and is easy to maintain, there may be little reason to change it.

If the team is afraid to modify a Flow because nobody understands its dependencies, that’s a different story.

Winter ’27 provides some better tools for dealing with that situation.

The bigger opportunity is using them to make Salesforce simpler and more reliable, rather than adding another layer of complexity.

CTA: Is Your Salesforce Automation Getting Harder to Maintain?

When Salesforce has been customized over several years, even small changes can become difficult. Overlapping Flows, outdated processes, and unclear dependencies can make every release feel riskier than it should.

Revenue Ops LLC helps organizations review their Salesforce architecture, identify unnecessary complexity, and improve the processes that support sales, service, and revenue operations.