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

By

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.

Resources

Cloudy towing Einstein on water skiis next to text that says "Learn Moar: #2 Flow Enhancements."

Learn MOAR in Summer ’22 with Flow Enhancements 🔁

Follow and complete a Learn MOAR Summer ’22 trailmix for admins or developers by July 31, 2022, 11:59 pm PT to earn a special community badge and be automatically entered for a chance to win one of five $200 USD Salesforce Certification vouchers. Restrictions apply. Learn how to participate and review the Official Rules by […]

READ MORE
Image of Salesforce characters on a green field next to text that says, "Trailblazer DX '22 Admin Recap."

6 TrailblazerDX ’22 Takeaways for Salesforce Admins

Two weeks ago, TrailblazerDX returned, marking our first big in-person event together in more than 800 days! The energy, enthusiasm, and excitement on-site was equally matched by those joining us on Salesforce+, with two full days of content, connection, and collaboration. From keynotes to campfires and everything in between, TDX ’22 was full of knowledge […]

READ MORE
Greenery and text that says, "Automate the Assignment and Removal of Permission Set Groups." "

Automate the Assignment and Removal of Permission Set Groups

In the first episode of Automate This!, a new livestream content series focused on all things automation, I presented a solution for automating the assignment and removal of permission sets. This blog post will cover a related solution, the automation of the assignment and removal of permission set groups. Don’t know what permission set groups […]

READ MORE

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?

SHARE YOUR IDEA