Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Salesforce Flow context determines which permissions a flow uses—not simply who started it. User context applies the running user’s object and field permissions, while record access also depends on sharing. System context ignores object and field permissions; with sharing it still respects record-sharing controls, and without sharing it can access all data. Check the flow’s configured context and how it is called before deciding what access it actually has.
What is the running user of a flow?
The running user is the user whose access rules Salesforce applies when the flow performs its operations. In user context, that person’s profile and permission sets determine the flow’s object permissions and field-level access. Record visibility is also affected by sharing controls, including organization-wide defaults, role hierarchies, sharing rules, manual sharing, teams, and territories. If the running user lacks a permission an operation requires, that operation can fail.
The person who caused a record change is not necessarily the user whose access governs every flow operation. The flow’s type, configured run context, and caller chain all matter.
How do user and system context differ?
| Run context | Object and field permissions | Record sharing | Practical meaning |
|---|---|---|---|
| User Context | Uses the running user’s permissions | Respected | Suitable for user-facing flows that should honor the user’s access. |
| User Context–Enforces User Permissions | Enforces the running user’s access even if a system-context flow calls it | Respected | Available for screen and autolaunched flows on API version 68.0 and later, according to Salesforce’s Winter ’27 release documentation. |
| System Context with Sharing | Not enforced | Respected | Can access records the user may not otherwise be able to reach through object or field permissions, but still follows record-sharing controls. |
| System Context without Sharing | Not enforced | Not enforced | Can access all data; use only when the flow’s requirement justifies this level of access. |
“With sharing” does not mean that object permissions and field-level security are enforced. It means record-sharing controls remain in effect. Salesforce defines these modes in Set Flow Run Context.
#1 Best Overall
Does a record-triggered flow run as the user?
Not by default: Salesforce lists record-triggered flows as running in system context without sharing. Schedule-triggered and platform-event-triggered flows also default to system context without sharing. Many direct launch methods instead default to user context. These defaults are tied to how the flow is launched, not to a universal rule that applies to every flow.
| Launch method | Documented default |
|---|---|
| Experience Cloud site; embedded visual component in custom Aura or Visualforce; custom button or link; direct link; flow action; Lightning page; REST API; web tab | User context |
| Platform event; Process Builder process; record-triggered flow; schedule-triggered flow | System context without sharing |
| Apex or a flow launched from an Apex controller method | Depends on code |
These are defaults, so inspect the flow’s run-context setting and the entire caller path. Salesforce notes that Lightning screen components and local actions always run in user context. A flow called by Apex always ignores object and field-level access permissions; the Apex sharing declaration affects record-sharing behavior. A flow also always runs in user context when it performs the Post to Chatter action. See Salesforce’s Flow Run Context guidance for the launch-method details.
Can a system-context caller elevate a user-context flow?
Yes. A flow configured in standard user context can inherit elevated permissions from a system-context caller. That can make the effective access broader than the child flow’s setting alone suggests.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →For screen and autolaunched flows on API version 68.0 and later, Salesforce documents User Context–Enforces User Permissions as an option to keep access at the running user’s level regardless of caller. This setting is limited to those flow types and the documented API version threshold; it is not a universal setting for every flow. Confirm availability and labels in the relevant org and release.
Is Run Flows permission the same as data access?
No. Run Flows permission controls whether a user can directly run specified flows. It does not grant the object, field, or record access needed for the flow’s operations. Conversely, system-triggered flows run automatically and do not require the initiating user to have Run Flows permission. Salesforce explains this distinction in Limit User Access to Run Flows.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which context should you choose?
For screen flows
Start with user context when it can meet the business requirement. Salesforce recommends running screen flows in user context whenever possible because it enforces permissions that restrict user access to data. This is especially important for flows exposed to external users through Experience Cloud.
When one operation needs extra access
Avoid elevating an entire screen flow just to support one privileged operation. Salesforce documents isolating that work in a separate system-context autolaunched subflow where appropriate. Keep the subflow’s inputs and outputs limited to what it needs, and retrieve only the fields required for the operation. This reduces the amount of data that a broader context can access or expose. See Data Safety When Running Screen and Autolaunched Flows in System Context.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesFor system-triggered automation
Choose a context based on the automation’s required access, not on assumptions about the record owner or the user who initiated the change. If system access is necessary, be deliberate about whether record sharing should still apply and limit the data the flow retrieves and passes onward.
Quick Recap
Best Value
How to troubleshoot a flow access failure
- Identify how the flow starts. Check whether it is triggered by a record, schedule, platform event, direct user launch, Apex, or another flow. The launch path supplies a default context.
- Inspect the flow’s configured context. Do not rely on the launch default alone; verify the actual setting in Flow Builder.
- Trace the caller chain. A system-context caller can affect a standard user-context flow. For screen and autolaunched flows on API version 68.0 and later, check whether User Context–Enforces User Permissions is appropriate.
- Check each access layer. For user context, review the running user’s object permissions, field access, and record sharing. For system context with sharing, check record-sharing access even though object and field permissions are not enforced.
- Check Run Flows permission only when relevant. It governs direct execution access, not the data permissions needed by flow operations; system-triggered flows do not require the initiating user to have it.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
