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!
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.
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:
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.
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.
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.
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.
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.
As an Awesome Admin, it’s probably in your nature to look for any way to optimize a process or situation! As part of that never-ending desire for optimization, I would bet that you’ve spent a lot of time thinking about your permissions setup in Salesforce. Salesforce provides multiple ways to grant permissions to users, each […]
Ready to take the next step in your admin career but unsure where to start? Take a page out of my book and learn development fundamentals to jumpstart your abilities as an advanced admin and extend your Salesforce Platform knowledge. Several years ago, I was at a career tipping point. I felt solid in my […]
Winter ’25 is almost here! Learn more about some of the features coming to Flow and check out Be Release Ready to discover more resources to help you prepare for Winter ’25. General Flow enhancements With Winter ’25, we’re introducing several features that will streamline the flow creation experience and simplify the maintenance of existing […]
