Original OrbTrail analysis expanded with complementary research, practical context and verified references.
The Winter ’27 release notes introduce User Context—Enforces User Permissions for screen flows and autolaunched flows. When selected under How to Run the Flow, it keeps execution at the user’s access level even when another component invokes the automation. The change addresses a persistent risk: an autolaunched flow normally inherits its caller’s context, so identical logic can encounter a different set of objects, fields and records when launched from a screen, another flow or an automated action.
The central question is not whether user context is safer in the abstract. It is whether the identity arriving at the flow represents the person whose access should constrain the operation. In user context, official guidance says a flow reaches only objects, fields and records available to the running user. System context with sharing preserves record sharing but not object or field permissions; without sharing, all three layers can be bypassed. The new option makes a conservative choice persistent, but it does not change who the running user is.
OrbTrail reads the feature as an authorization contract at the flow boundary. It is particularly useful for reusable automation whose author cannot control every future caller. Instead of trusting each screen, subflow or action to preserve a safe context, the flow declares that it will not accept inherited elevation. That reduces architectural surprise, while moving the work to two measurable activities: designing the minimum permission set for every persona and proving that each caller supplies the expected identity.
Identity crosses the boundary
A screen, subflow or agent supplies the running user. The channel name does not prove whom that identity represents.
User context stays pinned
The Winter ’27 option prevents the flow from inheriting broader execution merely because its caller changes.
CRUD, FLS and sharing are checked
Object, field and record access must all sit within the execution identity’s effective permissions.
The permitted action runs
Get, Create, Update or Delete proceeds only when the persona holds the required permission combination.
Failure becomes a designed outcome
Fault paths and useful messages should explain missing access without disclosing data the user could not retrieve.
What changes when a flow stops inheriting its caller’s privilege
Historically, default context depends on automation type and position. Salesforce Admins guidance records that a top-level screen flow runs in user context by default, while an autolaunched flow inherits the context of its invoker unless explicitly configured. A routine that appears safe in a manual test can therefore behave differently when reused by a system-context caller. The new option removes that variation for the two supported types: the policy belongs to the flow and follows every invocation route.
The feature does not turn record-triggered or schedule-triggered flows into user automations; the release note limits it to screen and autolaunched flows. Nor does it grant access. Trailhead distinguishes permission to run a flow from the permissions its elements need: a user can start the automation yet fail to create a Case, edit a protected field or retrieve a private record. That is a useful denial when it reveals an incomplete permission set, and a poor experience when the flow offers no fault path or actionable guidance.
Implementation should begin with an inventory of inputs and effects. For every Get, Create, Update, Delete and invoked action, record the object, fields read or changed and sharing condition. Then run the same case as a minimum-access persona, an operating persona and an administrator. Acceptance is not administrator success alone. It is success for the intended access, denial for the unintended access, and no protected value leaking through the screen, user-facing error or log.
Less implicit privilege requires explicit failure design
Pinning user context can turn access previously masked by system mode into visible errors. That is not automatically a regression; it often reveals that the process depended on silent elevation. The right response may be a narrow permission, removing an unnecessary field from the flow, or isolating a privileged operation in a separate service. Returning the entire flow to system context simply to clear the error restores functionality by broadening the data surface.
Consider a support screen flow that creates a Case and updates a review field. The team can grant Create on Case and Edit only on necessary fields through a dedicated permission set. If the review field belongs to quality staff, the agent flow should not write it invisibly; a later automation with its own identity and purpose can own that step. The boundary between routines documents why elevation exists and reduces the number of elements operating above the user.
Test denial as part of the product. The message should say that the operation could not complete and provide a next step without exposing names or values from inaccessible fields. Administrative telemetry should capture flow, version, element, identity and error class; users should not copy a technical stack trace. Compare failures by permission set before and after migration. A spike isolated to one persona suggests an incomplete access contract, while failure only on a private record points to sharing rather than CRUD or FLS.
In Agentforce, user context does not mean customer context
The distinction becomes critical when an autolaunched flow is an agent action. Salesforce security documentation says an employee-facing agent executes the action with the identity of the user who submitted the prompt, while a service agent uses the agent’s identity. Selecting User Context can therefore constrain an internal agent to the employee’s access. In external service, however, it constrains the agent user; it does not automatically make the authenticated or verified consumer the running user.
For private service-agent actions, the official guide requires customer verification and data scoping to that identity. Its example passes VerifiedCustomerId from controlled context, validates the value and limits every returned or altered record to that customer. The new flow mode is complementary: it contains what the agent identity can do in the org, while verification and relationship logic contain what this particular customer may ask the agent to do.
Before publishing an action, build four cases: authorized employee, employee without access, verified customer related to the record and verified customer related to a different record. Add a manipulated input, nonexistent ID and sensitive mutation without confirmation. The action passes only when every denial occurs before data is returned and explicit confirmation protects effects such as sending email or making an irreversible change. OrbTrail’s conclusion is that Winter ’27 provides a more dependable flow boundary, but security still comes from composing the right identity, least privilege, record scope and predictable error handling.
