#Agentforce528 人正在讨论

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.

Hi Purushottam, the key thing is the agent runs server-side, so it cannot read the browser URL itself. You extract the params on the host page and pass them in as context. For an embedded Messaging for In-App and Web (or Enhanced) deployment: 

1. In your page's embedded messaging snippet, read location.search and parse param0, param1, param2. 

2. Pass them in through the Pre-Chat API just before the chat launches: embeddedservice_bootstrap.prechatAPI.setHiddenPrechatFields(...). Hidden pre-chat fields carry the values in with no visible form. 

3. Map those onto custom fields on the Messaging Session, then expose them as Messaging Session Context Variables in your agent config. 

4. Reference those context variables in the agent's topic instructions or actions to shape the response. 

If you are calling the headless Agent API instead of the embedded widget, pass the same values as context variables when you start the session. 

So the agent never reads the URL directly, the page reads it and hands the values to the conversation as context. 

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

Hi Steffany, 

This looks like a picklist-cache timing issue, not bad data — your workaround (reselecting the same value) confirms it, since the exact same value that failed then gets accepted. 

What's happening: "Add Asset from Library" copies the Reference Action value before the restricted picklist re-indexes the newly added Apex action as valid, so Commit rejects it as "not a recognized value" even though it's correct. 

Try: 

1. Hard refresh Agentforce Builder after adding the asset, before committing. 

2. Commit once manually in your source org (fixing the picklist there), then package that already-committed state — so subscribers don't hit it fresh. 

3. If reproducible from a clean scratch org, file it as a bug via Partner/ISV Support — this is a packaging-specific platform issue worth escalating there. 

Reference: