Mountains and greenery and text that says "Guide to Determining Flow Running User and Its Execution Context."

Your Guide to Determining the Flow Running User and Its Execution Context


When you build automation in Flow Builder, it’s important to understand how the running user affects your flow. The running user determines how your flow runs. Knowing who the running user is allows you to know who creates or modifies the records in the flow and helps you debug issues when they arise. It’s also important to know how the running user affects the context in which your flow runs, since permissions and record access can vary between users. I know this may sound confusing, but I’m here to help clarify it all for you. Let’s dig in!

Who’s running my flow?

The running user of a flow is the user who launched the flow, which can either be the current user or the Automated Process user. The running user determines what a flow that runs in user context can do with Salesforce data.

The running user and execution context for each flow type.

All flows, with the exception of scheduled-triggered flows, will run as the current user. When you have DML actions in your flow (actions that either create, edit, or delete records), the current user running the flow is:

  • The user who will be stamped as the record creator (in the case of record creation),
  • The user who last modified the record (in cases of record update or deletion), or
  • The user performing an action (in the case of a flow action, get records, or invoking a subflow).

If you’re debugging or troubleshooting a flow error, you’ll look for the flow to be run as the current user.

Additionally, platform event-triggered flows that are standard platform events are sometimes published by the Automated Process user. However, Apex Debug Logs will show the flows run as the Automated Process user regardless of whether the platform event-triggered flow was run by the current user or Automated Process user.

For scheduled-triggered flows, if your flow is saved with an API version below 53.0—and for API versions 53.0 or greater and without a designated workflow user—your scheduled-triggered flow will run as the Automated Process user. If you’re troubleshooting or debugging a flow error, Apex Debug Logs will show this as the Automated Process user. Note: By default, when you create a flow, it’s configured to run in the latest API version.

To check the API version of your flow, access the flow properties, select Advanced, and locate the value in the API Version for Running the Flow field.

A flow’s properties with the Advanced attributes expanded to show the API Version for Running the Flow field.

To set the workflow user, go to the Process Automation Settings page, then search for and select the user you want to set as the Default Workflow User.

Process Automation Settings page where you can set the Default Workflow User.

What context is my flow executed as?

There are three contexts a flow can be executed as: user, system context with sharing, and system context without sharing.

The running user of a flow is important because when a flow creates, retrieves, edits, or deletes Salesforce data, it enforces the running user’s permissions and field-level access.

If a flow is running in user context, it will use the running user’s profile and permission sets to determine the object permissions and field-level access of the flow. A flow that runs in system context with sharing has permission to access and modify all data, but will respect record access permissions as determined by organization-wide default settings, role hierarchies, sharing rules, manual sharing, teams, and territories. However, it doesn’t respect object permissions, field-level access, or other permissions of the running user. Lastly, if a flow is running in system context without sharing, the flow has permission to access and modify all data, ignoring all record access permissions. Note: You should set a flow to run in system context without sharing sparingly, as it will give the running user access to records they would not normally have elsewhere in Salesforce.

Visual representation of each flow type and its execution context.

Record-triggered, platform event-triggered, and scheduled-triggered flows are run in system context without sharing.

Autolaunched flows inherit the context of their caller (except Apex) by default, or run in system context with or without sharing, if explicitly selected. If an autolaunched flow is invoked from Apex, the flow will always run in system mode without sharing, regardless of which mode the flow is set up to run as.

Top-level screen flows run in user context by default, or system context with sharing, if explicitly selected. A top-level screen flow is the initial or first screen flow in a flow that has multiple screen flows.

Lower-level screen flows inherit the context of their caller (initial flow) by default, or run in system context with sharing, if explicitly selected. A lower-level screen flow is a screen flow that’s a subflow invoked from another screen flow.

Note: There are components (lookup, address, dependent picklist, file upload, dynamic forms for flows or any component that goes to the database to retrieve data) in screen flows that will run while respecting the running user’s permissions even though the screen flow is set to run in system context.

Now you know, so you can flow

Flow is a powerful tool, and it can be even more powerful now that you know how to consider the running user in the context of your own automations. #LetItFlow! For more automation content, check out our Automation page on our site.


Greenery next to text that says," Three Powerful Formula Functions You Can Use in Flow"

Three Powerful Formula Functions You Can Use in Flow

Often times in automation, you want activities to occur only when the record is new, when the record is updated, or when there was a record update but only if the previous field value was ‘x’. The power formula functions IsNew(), IsChanged(), and PriorValue() that you use in workflow rules and processes can also be […]


AI for Admins: What You Need to Know to Make Einstein Bots a Success

Einstein Bots interact with your customers quickly and accurately with automation and artificial intelligence (AI) capability. In terms of AI initiatives, the biggest challenge is measuring business impact. One reason most AI projects fail is that people are looking at “model performance” instead of business value, such as how much money, in either additional revenue […]

Mountains and greenery next to text that says, "Share User Feedback in Slack with OmniScripts."

Seamlessly Share User Feedback in Slack with OmniScripts

⚠️ The challenge As #AwesomeAdmins, we’re used to managing our Salesforce orgs and constantly making our best efforts to turn user feedback into actionable enhancements together with the development team. Now let’s imagine it’s the go-live day of a brand new, industry-specific component. We’re all so excited about it and we want to enrich it […]


Have an Idea for a Story?

We are all about the community and sharing ideas.
Do you have an interesting idea or useful tip that you want to share?