Salesforce Flow Run Context, Explained: User vs System Context

Every Salesforce flow runs as someone. Most days you never think about it — the flow just works. Then a screen flow that behaves perfectly for you throws "insufficient privileges" for a sales rep, or an autolaunched flow quietly updates records a user was never meant to touch. That is run context at work: the set of permissions your flow borrows while it executes.

The two worlds: user context vs system context

User context means the flow runs with the launching user's permissions. Object access, field-level security, sharing rules, the role hierarchy — all enforced exactly as if the user were clicking through the records themselves. If the user cannot see a field, the flow cannot read it either.

System context means the flow bypasses the user's object and field permissions. It comes in two flavors: with sharing still respects record sharing rules and the role hierarchy, while without sharing removes even those guardrails — the flow can touch any record in the org.

Each launch method ships with a default. Screen flows launched from a Lightning page run in user context; record-triggered and schedule-triggered flows run in system context without sharing. And flows can inherit elevated access from the flow that called them — context flows downhill.

The four options in Flow Builder

On newer API versions (v68.0 and later) you get explicit control over this for screen and autolaunched flows:

• User or System Context — let the launch method decide (the default behavior).
• User Context – Enforces User Permissions — always the user's access, even when a system-context flow calls this one. Use it when a flow must never gain elevated access.
• System Context with Sharing — ignores object and field permissions, but respects sharing rules.
• System Context without Sharing — no object, field, or record-sharing restrictions at all.

Setting it takes ten seconds: open the flow in Flow Builder, click View Properties, then Show Advanced, and under How to Run the Flow pick your context and save. If the dropdown is greyed out, that flow type does not support changing run context.

You will need the Manage Flow permission to touch these settings (it covers flows that use Einstein and Agentforce for Flow as well).

Gotchas worth knowing

• Experience Cloud is the danger zone. A screen flow running in system context on a public or community site can expose internal data to external users. Default to user context there unless you have a very specific reason not to.
• Some elements ignore your choice. Lightning screen components and local actions always execute in user context. The Post to Chatter action always runs in user context too.
• Apex can rewrite the picture. Flows launched from Apex may bypass object and field permissions depending on the calling code's sharing declaration — with sharing versus without sharing on the class still matters.
• Watch inherited context. When a system-context autolaunched flow launches a subflow, the subflow can inherit that elevated access. Trace the chain before you assume the user context applies.

The bottom line

Run context is a security decision wearing an admin setting's clothes. Default to user context when the flow acts for a specific person; reach for system context only when the flow needs data the user legitimately cannot reach — and prefer with sharing over without sharing when you do. Set it deliberately once, and you will never debug a phantom permissions error at midnight again.

Originally published at Way2Force.