Salesforce Flow user context in Winter ’27: make permission boundaries predictable

Salesforce’s Winter ’27 preview includes a small-looking Flow setting with an important security consequence. A new User Context–Enforces User Permissions option allows a screen flow or autolaunched flow to keep running with the initiating user’s access level, even when it is called by automation that has elevated system access.

This addresses an execution-context edge case that is easy to miss during design reviews. Previously, a flow configured for user context could inherit system-level permissions from its caller—such as another flow, Apex or other automation. The flow’s label and the builder’s intention could therefore suggest one security boundary while the runtime chain produced another.

The new option can make that boundary explicit. It is not, however, a reason to change every flow. Platform teams need to understand where user permissions are part of the business rule, where elevated processing is genuinely required and what users will experience when access is correctly refused.

What Salesforce has confirmed

Salesforce’s Winter ’27 release notes describe the option as available for screen flows and autolaunched flows. It applies only when the flow runs on API version 68.0 or later. In Flow Builder, it appears under the advanced run settings as User Context–Enforces User Permissions.

Salesforce says the setting keeps the flow at the running user’s access level regardless of what launches it. That means the flow can enforce the user’s object permissions, field-level access and record access instead of inheriting its caller’s elevated context.

Winter ’27 is still in preview at the time of writing. Salesforce’s current release calendar lists production upgrade weekends beginning on 4 September 2026, followed by 2 October and 9 October, but each organisation should confirm its own instance maintenance window in Salesforce Trust. Preview features and documentation can change before general availability.

Why nested automation needs attention

Flow context is not determined only by the canvas being reviewed. Salesforce documents different defaults for different launch methods. Screen flows commonly begin in user context, while record-triggered, platform-event and schedule-triggered flows commonly run in system context without sharing. Autolaunched flows can inherit context from whatever called them.

This matters when automation is composed from reusable parts. A subflow may have been designed on the assumption that it respects the initiating user’s permissions, yet a later project can reuse it beneath a system-context parent. Without reviewing the complete call chain, administrators may not realise that the effective access changed.

The risk is not limited to obvious updates. Get Records can return fields or records that the user could not otherwise access, and outputs can pass that data back to a screen component or another part of the automation. Salesforce’s data-safety guidance is especially cautious about screen and autolaunched flows exposed to Experience Cloud users.

The confirmed product change is the new context option. The Ostrelis interpretation is that it should prompt a broader review of security assumptions in reusable automation—not a mechanical update of every flow version.

Where the new option is a good candidate

Start with flows where the business rule is explicitly tied to the running user’s authority. Examples include a guided update that should edit only fields the user can edit, a self-service process that should return only records the user can see, or a reusable autolaunched flow that must not gain more access when a privileged caller reuses it.

These are strong candidates because a permission failure is meaningful: it confirms that the organisation’s configured access model still governs the transaction. The new setting reduces dependence on every upstream designer remembering the downstream flow’s intended boundary.

It can also support clearer assurance. A reviewer can see that the flow is intended to enforce user permissions throughout the invocation chain, then test that statement with representative users. That is more reliable than relying on a convention recorded only in documentation.

Where system context can still be legitimate

Some automation deliberately performs an operation users cannot perform directly. A service process might create a controlled audit record, assign work, or update a protected integration field after validating a request. Salesforce provides system-context modes for such cases, including a mode that respects sharing and one that does not.

The correct response is not to remove every elevated action. It is to minimise and isolate it. Salesforce’s current Flow guidance recommends using user context where possible and, when elevated processing is necessary, separating that operation into a narrowly scoped system-context subflow. Inputs, outputs, fields and records should be limited to what the operation needs.

A change to enforced user context can also create genuine failures if users lack required object, field or record access. That may expose an inappropriate permission gap, or it may show that the automation was intentionally mediating a controlled task. The business owner and security owner should decide which interpretation is correct before permissions are widened.

A practical assessment method

1. Inventory candidate flows. Find active screen and autolaunched flows, record their API versions, run settings, entry points and downstream subflows.
2. Map the call chain. Identify whether each flow can be launched from a page, action, API, Apex, record-triggered flow, scheduled process or another path. Do not infer runtime context from the child flow alone.
3. Mark sensitive operations. Record every read, create, update and delete involving confidential fields, private records, permissions, identity data or regulated information.
4. State the intended boundary. For each operation, decide whether the running user’s permissions are part of the rule or whether the platform is meant to perform a controlled elevated action.
5. Choose a narrow pilot. Select a well-understood flow with representative callers and a clear rollback route. Create a new version rather than altering active behaviour without traceability.
6. Test positive and negative cases. Use users with the expected access, limited access, different sharing visibility and no access. Confirm both successful outcomes and safe failures.
7. Review diagnostics and support. Ensure faults produce useful operational evidence without revealing restricted data. Give support teams a way to distinguish a legitimate permission refusal from a broken automation.

Testing needs to prove the boundary

A successful administrator test is insufficient because administrators often have access ordinary users do not. Test using representative permission sets, field-level security and record-sharing positions. Include users who should be denied so that the control is proved rather than merely assumed.

Exercise every important invocation path. The same autolaunched flow may behave as expected from a user-launched screen but differently when reached from Apex or system automation. For Winter ’27 candidates, confirm the flow version uses API 68.0 or later and that the selected run setting is preserved in deployed metadata.

Then test the business transaction, not only the Flow interview. Check downstream records, notifications, integrations, duplicate prevention, rollback behaviour and error routing. A stricter permission boundary that silently leaves a process half-complete is not production-ready.

Governance after adoption

Add run context to the minimum design record for important flows. A review should capture the initiating user, every caller, effective context, elevated operations, data exposed through inputs and outputs, required permissions and negative tests. Revisit that record when a reusable flow gains a new caller.

Deployment reviews should treat API-version changes and run-context changes as behavioural changes, not housekeeping. Monitor failed interviews after release, but avoid responding to every permission error by granting broader access. The first question should be whether the refusal reflects the intended security model.

Salesforce separately controls who can run flows through the Run Flows permission and flow-specific access. Those controls decide who can start eligible flows; run context decides what the flow can do once running. Both need review.

The Ostrelis view

The most useful feature of the new setting is predictability. Complex automation is easier to govern when a reusable component can carry an explicit security boundary instead of inheriting unexpected privilege from a caller.

Adopt it selectively. Begin with user-facing and reusable flows that handle sensitive data, document the intended boundary, test with realistic users and isolate any genuinely elevated operation. That approach improves least-privilege design without breaking valid service automation in pursuit of a blanket rule.

Ostrelis can help inventory Flow dependencies, review execution context, design safer permission boundaries and manage sandbox testing through a controlled release process. See our Salesforce Flow and automation services, managed Salesforce support and approach and experience.