Agentblazer Community Group

Hi Ashish!

Yes, Agentforce Contact Center (ACC) can be explored for a quick POC, but the standard Trailhead Playground may not have all the Contact Center/voice features provisioned by default. 

I’d suggest checking the latest Salesforce trial or a specially provisioned Agentforce/Contact Center org rather than a regular Developer Edition. If you’re looking specifically to test voice, routing, telephony, or service-agent integration, the available features can also depend on the org provisioning. 

If you share what part of ACC you want to POC (voice, routing, Agentforce Service Agent, etc.), I can point you toward the most suitable org/trial setup.

Hi Shalini, 

For Step 4, @actions.Get_Customer_Details needs to be available as an action before you can reference it in the Agent Script variable. 

I’d first check that the Get Customer Details action was created/configured in the same Agent and that the action’s API name is exactly Get_Customer_Details. Then save/activate the action and refresh the Agent Script Builder before trying to reference it.

Also make sure you’re working in the same Playground/org associated with the challenge, as actions created in another org won’t appear in the script. 

If the action already exists and you still can’t find it under @actions, share a screenshot of the action configuration and the Step 4 variable/script. That should help identify what is missing.

Hi @Bríet Konráðsdóttir

This isn't really an async-vs-sync issue - it's that the

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: 

1. 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
2. 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.

Hi @Karl Abellera

, 

Short Answer:  There are few things you can do with AI (without knowing Apex and Flows). However, you need to have at least basic understanding of Apex and Flows to know what is going on. 

In case you wish to check (very quickly, within 1 hour or less), you can try this module:

. 

A pre-configured and easy to understand - you will get an idea what is possible to edit via AI. 

If this is useful, please mark appropriate responses as helpful/solution, so that other people may reach to the solution quickly. 

Hi @Matt Devine

12,000 Einstein Requests in one day is definitely worth investigating before expanding the rollout. I’d first check Digital Wallet to identify exactly what is consuming the requests and verify your Agentforce Coworker licensing and user AI permissions. 

Since this was only one day of testing, I’d also run a small pilot with a few users and track consumption per user/use case before estimating production usage. Since you’re using Data 360, check that usage separately as well. 

For a nonprofit, I’d recommend measuring and optimizing usage first, then comparing the available licensing options to find the most cost-effective approach.  

Hope this helps!