#AgentforceBuilder15 debatiendo

Hi @Sourabh Dondekar Yes, this is expected. Flex Credit consumption is viewed through Digital Wallet in Production, even for Sandbox usage.

A few key points:

1. Digital Wallet consumption details are available in Production.
2. Sandbox usage can be tracked from the Production Digital Wallet.
3. Make sure you have the required permissions to view consumption details.

Check Digital Wallet in your Production org. You don't need to enable any separate setting in Sandbox.

Hope this helps!

Short answer: it's near real-time, not instant.

From Salesforce Help (Monitor Usage for Consumption-Based Products in Digital Wallet): "Consumption information is updated multiple times a day but can take longer in some situations." Each consumption card shows a Last Processed date and time. Anything that ran after that timestamp isn't in the numbers yet.

Taking your questions in order:

1. Real time? No. Usage is collected and processed through Data Cloud data lake objects, so expect a lag of hours, not seconds.
2. Update frequency: "multiple times a day". The Last Processed time on the card tells you exactly how fresh the data is. Underneath, usage is stored at hourly and daily level (the TenantHourlyEntitlementConsumption and TenantDailyEntitlementConsumption DLOs).
3. Prompt templates called from record-triggered or autolaunched flows: no difference. They show up after the next processing run, not the moment the flow runs.
4. Verifying actual consumption:
   • Digital Wallet > Consumption Insights shows usage by type for a specific day or time period.
   • Build a Data Cloud report on the TenantEnrichedUsageEvent DLO. Salesforce built it for consumption reporting, and reports on it don't cost credits. Group by Usage Type Developer Name and Resource ID or API Name to see which agent, action or template used credits, and add Units Consumed. See the Help articles "Report On Usage by Feature With Digital Wallet" and "Create a Report on Usage by User ID".
   • If Digital Wallet and your invoice ever differ, the monthly statement is the source of truth.

Tip for testing: run your flow a known number of times, note the time, and check again after the next Last Processed timestamp. That gives you a clean per-run credit figure.

If you found this answer helpful, please mark it as helpful.

Hi @Manohar Goud

This is a common issue when we work with multiple subagents and actions in Agentforce.

Here are a few things I would suggest: 

1. Clear Responsibilities: Give each subagent a specific job. Try to avoid overlapping responsibilities.
2. Proper Instructions: Clearly explain when to use a subagent, when not to use it, and what it should do.
3. Meaningful Names: Use clear names and descriptions for subagents and actions so Agentforce can understand their purpose.
4. Avoid Similar Actions: If two actions perform almost the same task, try to combine them or clearly separate their use cases.
5. Use Agent Script: For complex or critical scenarios, use conditions and explicit routing instead of depending completely on AI decisions.
6. Availability Conditions: Use available when conditions wherever applicable to control which subagents or actions can be selected.
7. Handle Unclear Requests: If the user request is confusing, let the agent ask a follow-up question instead of choosing the wrong action.
8. Test Multiple Scenarios: Test different ways users might ask the same question, including negative and overlapping scenarios.
9. Monitor Agent Behavior: Review session traces regularly to understand why a particular subagent or action was selected.

For example:

If we have three subagents for Order Inquiry, Order Cancellation, and Order Modification, each should have clear instructions about which requests it handles.

In my view, the best approach is to start with fewer subagents and actions, test them properly, and then gradually add more. 

One important point: Don't depend only on AI instructions for critical business processes. Use proper conditions, permissions, and validations to control execution.

Hope this helps! 

Thank you, 

Venkat Yadav.

Hey Jiyaulla,

Here’s how I would approach the solution design:

1. Agent Boundaries & Routing

• Split by persona: Don't build one monster agent. Keep Employee Desk (IT/HR Q&A via Knowledge), Coworker (sales/service reps on record pages), and OOTB Service Agent in clean, separate buckets.

• Topics & Hand-offs: Limit each agent to 4–6 tightly scoped Topics. Write explicit "When to use" instructions so the reasoning engine doesn’t cross wires. Always map human escalation via Omni-Channel, carrying the chat summary over.

2. Actions & Grounding (The Engine)

• Actions: Use Autolaunched Flows for standard CRM updates and Invocable Apex for external API lookups. Keep JSON outputs short; feeding raw multi-page payloads burns tokens and slows reasoning down.

• Flex Prompt Templates: Stick to a 4-part prompt: Role, Grounded Context, Guardrails (what NOT to do), and exact Output Format.

• Knowledge & Data Cloud: If grounding with PDFs or policies, ensure your Data Cloud search indexes chunk properly. Watch Field-Level Security—if the running agent user can’t see the field, the LLM hallucinates.

3. Trust, Guardrails & Security

• Einstein Trust Layer: Decide upfront if PII needs data masking and where audit logs get retained.

• Hard Refusals: Put explicit negative prompts inside each topic (e.g., "Never disclose salary bands; route user to Workday").

4. Licenses & Consumption Reality Check

• Cost control: Agentforce bills per conversation, and custom prompt calls burn credits. Don't use the LLM for things a simple Flow lookup or formula can solve deterministically.

• Token limits: Heavy record grounding causes latency spikes. Keep grounding payloads minimal.

5. ALM & Deployments (Where Projects Trip Up)

• Metadata API: Topics, Actions, and GenAiPromptTemplate deploy through standard DevOps pipelines (Copado, Flosum, SFDX).

• Manual Post-Deploy: Playbooks always break here. You must manually:
  1. Assign permissions and FLS to the Agent Execution User.
  2. Activate the Agent version in Target Org.
  3. Validate Data Cloud search index syncs.

Hey Karthick, 

The errors in your second screenshot tell you exactly what's wrong: 

"Action input 'Guests' in 'Create_Experience_Session_Booking' has primitive type 'number' and does not require 'complex_data_type_name'" 

"Action input 'startDate' in 'Get_Sessions' has primitive type 'date' and does not require 'complex_data_type_name'" 

Basically, someone (or the auto-generation) set a complex_data_type_name on these two inputs, but that field is only meant for object or list[object] type inputs. Since Guests is a number and startDate is a date, both primitive types, that field should be empty for them. 

Fix: 

1. Open the Create Experience Session Booking action, find the Guests input parameter, and clear out the complex_data_type_name value, leave it blank 

2. Do the same for the startDate input in the Get Sessions action 

3. Save, then check the Problems panel again, the 2 warnings under it are worth reviewing too but the 3 errors should clear once these two inputs are fixed 

These usually come from the action being generated off a Flow or Apex class where the parameter metadata got mismatched. If you're pulling these actions from a Flow, double check the Flow's input variable data types match what's expected (number/date, not a record/object type) before regenerating the action. 

Reference: