I'm using Run Agent from an EmailMessage record-triggered Flow:
Incoming EmailMessage → Async Path → Run Agent
The agent works correctly in Agentforce Builder and when I debug the Flow as an admin.
When a real EmailMessage triggers the Flow, however, Run Agent fails with:
“Looks like you don't have access to this feature.”
The Flow error shows Current User: System.
My Default Workflow User is already set to an Integration User, but the async path still runs as System.
Is there a supported way to have Run Agent execute as a dedicated user with the required Agentforce permissions? Or is there another recommended pattern for this use case?
This isn't really an async-vs-sync issue - it's that the
whole transaction (sync and async) is executing without a real, licensed user identity, because the EmailMessage is being inserted by an automated process (Email-to-Case / inbound email handling), not a logged-in user. Default Workflow User won't fix this - that setting only governs the running user for legacy Workflow Rule field updates and email alerts; it has no effect on Flow execution context or on Agentforce actions at all. That's a common misconception worth ruling out explicitly.Salesforce's own guidance backs this up: agents should always use the permissions of the logged-in user, which means an integration invoking an agent should implement OAuth 2.0 Web-Server or User-Agent flow to force real user authentication. The native low code Run Agent flow action inherits whatever running-user context the Flow transaction has it has no "run as" override. When that context is the System/Automated Process user (no license, no permission set assignments possible), you get exactly the "doesn't have access to this feature" error, regardless of what the Default Workflow User is set to. Salesforce Developers
Two supported patterns, in order of recommendation:
- Call the Agent via REST (Agent API) from Apex, authenticated as a dedicated integration user - not the low-code Run Agent action. Set up a Connected App using OAuth 2.0 Client Credentials Flow mapped to a specific integration user that has the Agentforce permission set assigned, and have your async path invoke a small Apex class that makes the HTTP callout (Named Credential for the auth). This is exactly the pattern third-party connectors use to solve this same problem for example, one integration's setup docs have you configure a "Run as user" field under Client Credentials Flow, so the connector impersonates that user when invoking the Agent APIs. This decouples the agent call's identity from your Flow's internal running-user context entirely, which is the actual constraint you're hitting. UiPath
- Move the trigger point earlier, before the record enters system/automated context, if that's feasible for your Email-to-Case setup i.e., have a real user's context be part of the transaction that ultimately calls Run Agent. This is usually harder to guarantee reliably for inbound email and I wouldn't recommend architecting around it.
I'd go with option 1: build a thin Apex wrapper around the Agent REST API, called from your async path, authenticated via Named Credential tied to a dedicated Agentforce licensed integration user. It's more moving parts than the native action, but it's the only pattern that actually gives you a stable, permissioned identity independent of whatever triggered the Flow. Confirm you have an available Agentforce license to assign to that integration user before committing to this worth checking with your Salesforce AE if you're not sure of current allocation.
I hope you find the above information helpful. If it does, Please mark it as Best Answer to help others too.
