#Agentforce457 debatiendo

@KANAKA RANGARAO PARIMI The Agent Access tab isn't part of Agentforce Builder — that's why it's not showing there. It lives inside a Permission Set.

To grant access to your custom agent:

1. Setup → Permission Sets → open one (or create a new one).
2. In the Apps section, click Agent Access → Edit.
3. Add your agent from the list of active agents → Save. (It only appears here if the agent is Activated — if it's missing, activate it in Agentforce Builder first.)
4. Assign that permission set to the users who need the agent.

So the path is Permission Set → Agent Access, not the Builder. Once assigned, those users get access.

if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Hi @Connor Sus

, 

This is a classic "works everywhere except live agent execution" pattern, and it almost never means the flow/prompt template itself is broken it means the

1. LLM isn't actually populating the input the way you think (most common) Testing the Prompt Template directly and debugging the Flow directly both let you set the input value manually. When the agent calls the action, the LLM has to extract/slot-fill that value from conversation context or a prior action's output and it can silently pass an empty string, a malformed value, or the wrong field even though the action "fires" successfully. Variable name matching between the action and the flow (which you already checked) doesn't guarantee the value arriving at runtime is non-null or correctly shaped. 

→ Check this first: open the Agent Tracer / Conversation trace (Setup → Agentforce Agents → open the session, or Agent Tracer in Agentforce DX) and look at the actual JSON payload sent to the action for that turn not the flow debug log, the agent's invocation trace. Confirm the input variable has the value you expect at that specific call. 

2. Running-user identity differs from your test context For an employee-facing agent, the action executes as the identity of the user chatting with the agent not necessarily the identity you were using when you clicked "Preview" or "Debug" on the flow/prompt template directly. If Get Records relies on sharing rules, FLS, or a Data Cloud permission set, a different running user can silently get zero rows back with no error. The fact that another action on the same agent successfully pulls Data Cloud data doesn't rule this out that action may hit a different Data Model Object / Data Space with different permission grants. 

→ Confirm which user identity actually executes when the agent (not you manually) runs the action, and check that identity's access to the specific DMO/fields this Get Records is querying. 

3. Prompt Template's "Related Record" / grounding binding vs. the flow's input variable If this is a Flex-type Prompt Template, there are two separate places a value gets bound: the Prompt Template's own resolved input (e.g., a Related Record merge field) and the Template-Triggered Flow's input variable. These can be wired to different sources. Previewing the Prompt Template directly lets you pick the record manually Prompt Builder preview and agent execution don't necessarily resolve that binding the same way. 

→ In the Prompt Template, check exactly what the "Related Record"/input is bound to (context variable vs. static vs. agent-passed), not just that the flow's variable name matches. 

4. Silent Data Cloud query timing/async issue Less common, but if the Get Records is querying a Data Cloud DMO fed by a streaming/batch ingestion, there can be a timing gap between when data lands and when it's queryable unlikely to be your issue since you said the flow returns correctly in isolation, but worth ruling out if the timing of the agent call differs from your manual tests. 

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

 Hi @Anirban Guha

 Please make sure you are using the same Developer Edition/Trailhead Playground that was launched from the challenge. Also verify that the Sales Email Prompt Template configuration matches the module instructions exactly. 

If everything is correct, try refreshing/relogging into Trailhead, waiting a few minutes, and running Verify Step again. Sometimes Trailhead takes time to recognize the changes.  

If the issue still persists, it could be a verification issue on Trailhead's side, so I would recommend contacting Trailhead Support with the screenshot and challenge details.  

Hope This Helps!!

I encountered the same issue and solved it. Try these steps: 

Go to Setup > Marketing Cloud > Basic Setting  

Scroll down, at the section "Unified Individual" 

select "UnifiedssotIndividualMkt__dlm" at the dropdown for the Unified Individual Object.  

Try again to select the segment step in your campaign

Hello @SAKTHIABIRAMI LS

You must enable end-user languages in your Salesforce org's global language settings first. 

1. From Setup, use the Quick Find box to search for and select Language Settings.
2. Check the box to Enable End-User Languages and save your changes.
3. Agentforce Builder and open your service agent configuration; the additional locale/language fields will now be visible and accessible.  
    

 Hi @Rohit .

This appears to be related to the provisioning of the Agentforce Playground and the User License assigned to the user. The “Use Custom Agents” permission is license-dependent, so if the Salesforce User License doesn’t support it, the permission cannot be added through a Permission Set.  

Since you’re already using the Agentforce Playground provided by Trailhead, I’d recommend relaunching the Playground from the unit and verifying that the org is freshly provisioned. If the same error persists, it may be a Trailhead org provisioning issue rather than a configuration issue.  

Hope this helps! 

Hi Motlatso, 

This template is also referred to internally as "Agentforce SDR" — so if Setup shows the other five but not Lead Nurturing, it's usually one of these: 

1. Edition/license gap. Lead Nurturing (Agentforce SDR) requires specific Sales Cloud licensing tied to Agentforce for Sales — it's not automatically included with every Developer Edition or every Sales Cloud license type, unlike some of the other templates you're seeing. Check whether your org has the Sales Cloud edition/add-on this specific template needs. 

2. Dependent features not yet enabled. This template depends on supporting Salesforce Go features (Einstein Activity Capture, Salesforce Inbox connectivity, Data 360) being available in the org. If Salesforce Go itself isn't provisioned, the guided setup card for Lead Nurturing won't appear even though Agentforce is on. 

3. Region/rollout timing. Lead Nurturing on Agentforce Studio rolled out via the Salesforce Go guided setup experience — if your Developer/Trailhead org was provisioned before this became broadly available, it may not have synced in yet. 

What to try: 

- Confirm you're using a brand-new Trailhead Playground (not a reused org) — this module requires a fresh org per the standard Trailhead guidance. 

- In Setup, search "Salesforce Go" and confirm it's available/enabled — this gates the Lead Nurturing card specifically. 

- If it's still missing after a fresh playground, this is worth a Trailhead Help case, since it may be an org provisioning gap. 

Reference:

Start with a brand-new Trailhead Playground first — that resolves this for a lot of people hitting missing templates.