Skip to main content

Hi everyone. I’m running into an issue with an action and was hoping someone might have an idea of what I’m missing.

 

The setup is:

  • Agent action calls a Prompt Template
  • The Prompt Template calls a Template-Triggered Prompt Flow
  • The flow uses Get Records and Add Prompt Instructions to return information

 

Everything works correctly when I test the pieces individually. When I debug the flow as the agent, I get the expected output. When I preview the Prompt Template, it also returns the expected output.

 

The issue only happens when I test through the agent. The agent correctly identifies and calls the action, but the response comes back without the relevant information.

 

The data is stored in Data Cloud, but another action on the same agent is able to retrieve Data Cloud information successfully, so I don’t think it’s a Data Cloud permission issue.

 

I also confirmed that the variable used by the action matches the variable in the flow.

 

 

 

#Agentforce

1 answer
  1. Sep 4, 11:58 AM

    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

    input the agent hands the action at runtime differs from what you tested with. A few likely causes, ranked by how often I see this: 

    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.

0/9000