Flow running context and user access to run flows
Key Takeaway
Permission to start a flow doesn't decide what the flow can do with data. The flow's context decides that, so a flow can start and still fail.
Every flow runs in a context, which decides whose permissions apply when the flow reads or changes Salesforce data: the running user's, or the system's. Separately, a user needs permission to start a flow at all. Admins control both, so flows work for the right people without exposing more data than intended.
The three flow contexts
Context defines who is running the automation, and flows have three contexts.
| Objects and fields | Records | |
|---|---|---|
| User Context | Only those the running user can access | Only those the running user can access |
| System Context with Sharing | All | Follows the running user's record sharing |
| System Context without Sharing | All | All, ignoring sharing |
In these context names, "sharing" means record sharing:
- Org-wide defaults
- Role hierarchies
- Sharing rules
- Manual sharing
- Teams
- Territories
System Context with Sharing still respects all of these, but it ignores the running user's object permissions and field-level access.
In User Context, the flow enforces the running user's profile and permission sets.
For example, imagine a flow in User Context that tries to update the Account Rating field on an account. If the running user lacks edit permission on Account, or on the Account Rating field, the flow fails with an error.
As another example, imagine that the Opportunity org-wide default is Private and no opportunities are shared with the running user. A flow in User Context can't read or edit any opportunity records.