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.
Automation is one of our superpowers as Salesforce Admins, and modular flows make that power even stronger. If you’ve noticed, flows are everywhere! Your flow-building expertise is key to preparing your company for Agentforce by creating custom flow actions for agents. However, as we shift toward building autonomous agents, we must rethink our approach from […]
As 2024 comes to a close, it’s time to reflect on all that Salesforce Admins have accomplished. ✅ This year was packed with innovation, and one of the standout milestones was the launch of Agentforce, Salesforce’s new suite of assistive and autonomous agents. With Agentforce, you can build, customize, and deploy intelligent agents tailored to […]
As Salesforce Admins, we’re always looking for ways to automate processes and reduce manual work for our users. With the introduction of Agentforce, we have a powerful new tool that goes beyond traditional automation. Let’s explore how to create effective Agentforce agents that can handle complex tasks autonomously. This article is based on my session […]
