Agentblazer Community Group

Hi @James Waltz

Yes, but I couldn't confirm it works out of the box. The reliable route is a small custom agent action. 

What I verified 

• Employee-facing agents have a standard Draft or Revise Email action, which the reasoning engine picks automatically for drafting emails. It generates text with the LLM. I couldn't confirm it can take a template name and merge that template's content. The Help page for that action didn't load for me, so check it in your org.
• The Agentforce Service Agent on Email feature does use a Lightning email template, but only as a single wrapper structure for autonomous replies. It isn't a "pick any template on request" mechanism, so it doesn't fit your use case.

Build a custom agent action, a Flow first, with Apex only if needed: 

1. Inputs: template name and Case ID, collected from the rep's prompt.
2. Lookup: query EmailTemplate by name. With hundreds of templates, return the top few matches when the name is ambiguous, and let the agent ask the rep to pick one.
3. Render: merge the template against the Case, using Apex Messaging.renderStoredEmailTemplate or an equivalent Flow approach.
4. Return: hand the rendered body back to the agent. Optionally pass it through Draft or Revise Email to tailor the tone to the case.
5. Draft only: never send from this action. Have the rep review and send.

• Access: confirm the action respects template folder sharing, so reps only get templates they can already see. This matters with many teams' templates in one org. I haven't verified how the agent's running user affects this, so test it.
• Template type: Lightning and Classic templates use different merge syntax ({{{Case.Subject}}} vs {!Case.Subject}), so confirm which types you have.
• Naming: with this many templates, exact-name matching will be brittle. A naming convention or a metadata field such as team or use case will help.

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

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.