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 →Salesforce Flow’s run context determines which permissions govern the flow’s data operations. User context uses the running user’s object and field permissions, while record visibility is also affected by sharing. System context can bypass object and field permissions; its sharing setting determines whether record-level sharing still applies. The launch method provides a default, but the configured flow and its caller chain can change the effective access.
What “running user” means in a flow
The running user is the user whose access Salesforce evaluates for the flow’s operations. In user context, that user’s profile and permission sets determine object permissions and field-level access. Record access is separately governed by sharing, including org-wide defaults, role hierarchies, sharing rules, manual sharing, teams, and territories. An operation can fail if the running user lacks a required permission.
As an Amazon Associate I earn from qualifying purchases.
Do not assume the record owner or the person who initiated a record change automatically controls every operation. The flow’s type, configured context, and caller path all matter.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsUser context vs. system context
| Mode | Object and field permissions | Record sharing | Practical meaning |
|---|---|---|---|
| User Context | Uses the running user’s permissions | Respected | Usually appropriate for user-facing flows that should honor the user’s data access. |
| User Context–Enforces User Permissions | Keeps access at the running user’s level, even when called from system context | Respected | Available for screen and autolaunched flows on API version 68.0 and later, according to Salesforce’s Winter ’27 documentation. |
| System Context with Sharing | Object and field permissions are not enforced | Respected | Allows elevated object and field access while retaining record-sharing controls. “With sharing” does not enforce the user’s full permissions. |
| System Context without Sharing | Object and field permissions are not enforced | Not respected; the flow can access all data | A high-access mode that needs a clear business justification and careful limits on data access and exposure. |
Salesforce describes the distinction in its Set Flow Run Context guidance.
Does the person who starts a flow determine its access?
Not by themselves. Salesforce documents defaults based on how a flow is launched, but these are starting points rather than a universal rule. The configured flow context and any caller in the chain must also be considered.
Launch methods that default to user context
Salesforce lists Experience Cloud sites, embedded visual components in custom Aura or Visualforce, custom buttons and links, direct links, flow actions, Lightning pages, REST API, and web tabs as user-context defaults.
Launch methods that default to system context without sharing
Platform-event-triggered, record-triggered, and schedule-triggered flows, as well as flows launched by Process Builder, default to system context without sharing.
Launch methods that depend on code
For Apex and flows launched from Apex controller methods, behavior depends on the code. Salesforce also notes that a flow called by Apex always ignores object and field-level access permissions; Apex sharing declarations affect record-sharing behavior.
Additional exceptions matter: Lightning screen components and local actions always run in user context, and a flow always runs in user context when it performs the Post to Chatter action. Consult Salesforce’s Flow Run Context documentation and inspect the actual launch chain in your org.
Can a system-context caller elevate a user-context flow?
Yes. A flow configured in standard user context can inherit elevated permissions when invoked by a system-context caller. For screen and autolaunched flows on API version 68.0 and later, Salesforce provides User Context–Enforces User Permissions to keep the flow at the running user’s access level regardless of caller. This documented option is scoped to those flow types and API versions; do not assume it applies to every kind of flow.
The feature threshold is associated with Winter ’27 in Salesforce’s release documentation.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Is Run Flows permission the same as data access?
No. Run Flows controls whether someone can directly run specified flows. It does not grant the object, field, or record access needed for the flow’s data operations; those still depend on the effective run context and sharing. System-triggered flows run automatically and do not require the initiating user to have Run Flows permission, according to Salesforce’s Limit User Access to Run Flows guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which context should you choose?
For a screen flow
Start with user context when it meets 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 available to external users through Experience Cloud.
When only one operation needs elevated access
Rather than elevating an entire screen flow, consider isolating the operation in a separate system-context autolaunched subflow where appropriate. Limit the fields retrieved to those the operation needs, and expose only necessary inputs and outputs. Salesforce discusses these safeguards in Data Safety When Running Screen and Autolaunched Flows in System Context.
For system-triggered automation
Choose the context based on what the automation must do, not on an assumption that the user who changed the record should govern access. Review the flow’s configured context and what data the automation reads or changes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
How to diagnose an access failure
- Identify the flow type and launch path. Determine whether it is screen, autolaunched, record-triggered, schedule-triggered, or platform-event-triggered, and note every caller, including Apex or another flow.
- Inspect the effective context. Check the flow’s run-context setting and whether a system-context caller can elevate a standard user-context flow. For screen or autolaunched flows on API version 68.0 or later, verify whether User Context–Enforces User Permissions is the intended setting.
- Check object and field access. In user context, confirm the running user’s profile and permission sets grant the access required by each operation. In system context, remember that object and field permissions are not enforced.
- Check record sharing separately. System Context with Sharing still respects record-sharing controls; User Context also operates within the user’s sharing access. Review the applicable sharing configuration when a record is unavailable.
- Check Run Flows only when relevant. Confirm this permission if the user directly launches a specified flow. Do not treat it as a substitute for data permissions or assume it is required from the initiating user for system-triggered flows.
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.
