Flow Run Context

The context that the flow runs in impacts what the following flow elements can do with Salesforce data:

• Action
• Create Records
• Delete Records
• Get Records
• Subflow
• Update Records
• Any other flow element that accesses fields from a record

By default, a flow runs in user context or system context, depending on how the flow is launched. When a flow runs in system context, it runs in that context for all users, including users with the Guest User profile.

Running User of a Flow

The running user of a flow is the user that launched the flow. The running user determines what a flow that runs in user context can do with Salesforce data.

For a flow running in user context, the running user’s profile and permission sets determine the object permissions and field-level access of the flow. When a flow attempts to create, read, edit, or delete Salesforce data, it enforces the running user’s permissions and field-level access. For example, if the running user doesn’t have the edit permission for the Account object, and the flow attempts to update account records, an error occurs. If the running user doesn’t have permission to edit the Rating field on the Account object, and the flow attempts to update that field, an error occurs.

Org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories also impact what data is accessible to flows that run in user context. If the org-wide default of the Opportunity object is private, and no opportunity records have been shared with the running user, the flow can’t read or edit any opportunity records.

By default, a flow in user context can inherit elevated permissions from a system-context caller, such as another flow or Apex. If a caller running in system context invokes your user-context flow, your flow also runs in system context. To guarantee that your flow always runs with the running user’s access level regardless of its caller, select User Context–Enforces User Permissions in the flow version properties. This option is available for screen and autolaunched flows on API version 68.0 and later. See Set Flow Run Context.

Limitations

• Lightning components such as screen components and local actions always run in user context.
• If the context depends on code, Apex uses the with sharing and without sharing keywords to specify whether to enforce org-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories. A flow called by Apex always ignores object and field-level access permissions.
• When a record-triggered flow, schedule-triggered flow, or process invokes an Apex invocable method from a class with inherited sharing, the method runs in system context with sharing. The flows and process run in system context without sharing.
• If a process triggers the flow to launch, the user that triggered the process sometimes requires other permissions. For example, if a process launches a flow that attempts to save permission set license assignments without the running user having Assign Permission Sets, an error occurs.
• A flow always runs in user context when it runs the Post to Chatter action.
• The standard user context option doesn't prevent a flow from inheriting elevated permissions from a system-context caller, such as another flow or Apex. To enforce user-level access regardless of the caller, use the User Context–Enforces User Permissions option. This option requires API version 68.0 or later and is available for screen and autolaunched flows only.