Understanding the ‘Automated Process User’ & the ‘Default Workflow User’
When flows run, what they’re allowed to do depends on their permissions, and those are based on the concept of the ‘running user’. For some kinds of flows, this can be pretty obvious. When screen flows execute, the running user is the User who is currently logged into Salesforce when the flow is initiated. For others, it’s a little more nuanced. Take record-change triggered flows. One might guess that the owner of the record that changed would be the running user, but it’s actually the person whose action triggered the record change that determines what the flow can or cannot do. Then there’s the question of Schedule-triggered flows, where there really isn’t any obvious user to assign.
When Schedule-Triggered Flows were first released, they were built to use a special, hidden user called the Automated Process User (“APU” and sometimes referred to as the Autoproc user). The APU has been around for many years and is used in places other than Flow including Apex and Flow Orchestration. However, APU has some limitations. It doesn’t show up in places like Profiles and Permission Sets so it’s hard to assign specific permissions to it. It doesn’t have access to ConnectAPI’s which are used in a lot of Salesforce services.
Changing APU would be challenging because it’s enmeshed in a lot of different parts of Salesforce. And it would still have limitations: you might not want the permissions for your Scheduled-Triggered Flows to be the same as your Platform-Event Triggered Apex Triggers, for example, but there’s only one APU, even if you had an easy way to change its permissions.
So, the Automation group introduced a new concept: the Default Workflow User. This is just a pointer to a User account. Whatever permissions you give that User are exactly what your Schedule-Triggered Flows can do.
Let’s go into more detail.
Default Workflow User is the recommended way to control the access level of automations for Schedule-Triggered and Record-Triggered Flows
You assign a User to be the Default Workflow User in Setup → Process Automation Settings:
As you can see, the Default Workflow User becomes the running user of Schedule-triggered flows.
This feature was added in October, 2021 (API Version 53). Flows saved to earlier versions will continue use the Automated Process User. You can resave a flow to a later version number if you want to change this.
Orchestration, Apex, Platform Events, and More Use the Automated Process User
Flow Orchestration
Flow Orchestration uses the Automated Process User to send notifications. Note that in order to get the Automated Process User to successfully send email, you need to specify an existing Organization-Wide Email Address (i.e. the ‘From’ Address that your org will send as). That’s done here in Process Automation Settings:
Note that you can’t just type any email address in there. You have to go to Setup, configure an Organization-Wide Email Address, and confirm it. Once that’s done you can enter the email address in Process Automation Settings.
Apex
Apex triggers set to fire on the receipt of a Platform Event Triggers also use the Automated Process user. This knowledge article is old but may be useful.
Some Apex methods execute as the Automation Process User, such as this SandboxPostCopy interface that enables a class to be executed immediately after sandbox creation.
Other Services That Use Automated Process User
- Approval Process Knowledge Actions
- Automation triggered by Batch Uploading of Records, such as Duplicate Rules Management. (Discussion)
Platform Events and the Automated Process User
When automation is triggered by a Platform Event, the running user actually varies depending on what’s triggered:
- Traditional Apex Triggers execute as the Automated Process User, as described above.
- Process Builder processes execute in the context of the user who fired the platform event (although they still show up in debug logs as the Automated Process User) (documentation)
As this knowledge article explains. The limitations on access that the Automated Process User normally encounters can cause Apex Triggers to behave oddly, and better results might be obtained by switching to a process from Apex.
The Automated Process User will trigger follow-on automation, such as workflow rules, validation rules, and flows, unless it has been assigned a more limited permission set, as described below.
Access and the Automated Process User
Triggered flows that use the Automated Process User run a flow in System Context without Sharing, which is the highest amount of access. However, there are some things that Automated Process User doesn’t have access to by default, such as Connect API’s.
It is possible, however, to assign a permission set to the APU. You can’t do it in Setup UI, but you can use Developer Console to assign a permission set to the User that has an alias of ‘autoproc’:
insert new PermissionSetAssignment(
AssigneeId = [SELECT Id FROM User WHERE alias = ‘autoproc'].Id,
PermissionSetId = ‘<your Permission Set Id here>’
);
Kudos to Roy Lloyd and Dan Moore for figuring this out! Keep in mind that if you follow recommendations and use Default Workflow Users you won’t have to do this.
Tracking the Automated Process User
You can log information about the Automated Process User in Setup →Environments → Logs → Debug Logs and you can see it in the View Setup Audit Trail (credit to Bill Wu for this information):
Note that if you have Sharing set to Private as an Organization-Wide Default, records owned by the Automation Process User will not be visible generally. However, there’s a setting that you can opt to use that will help with this. This is discussed here and addressed in this Spring ’22 improvement.
More on Automated Process User and Setup Audit Trail
Record-Change Triggered Flows Usually Have a Running User That They Can Use
Record change triggers normally use the Running User to determine access, for both the immediate automation and for any scheduled-paths. This is the User that initiated the record change (e.g. the logged in user editing a record in the UI, or the logged-in user making an record-update API call). For scheduled-paths, however, if that user has been deactivated (presumably in the interval between the record save and the scheduled-path execution), it switches to the Default Workflow User (with secondary fallback to Automated Process User if Default Workflow User is somehow not set, although an activation warning is issued on save if it isn’t set).