#Prompt Builder16 debatiendo

Yes. Turn on the Einstein generative AI audit data. You can then see the exact prompt that was sent to the LLM, and the exact response, for every call, including the ones fired from your record-triggered flow.

How to see it

1. Setup > Einstein Setup: turn on Einstein Generative AI data collection and storage (audit and feedback data). Data Cloud must be provisioned in the org.
2. Do one real end-to-end transfer again.
3. In Data Cloud > Query Editor (or a Data Cloud report), look at GenAIGatewayRequest__dlm. The maskedPrompt__c field holds the fully resolved prompt that actually went to the model (after Trust Layer masking), and userId__c shows which user the call ran as. The model's answer is in GenAIGeneration__dlm.responseText__c. New records can take a little while to show up.

What to look for

• Compare the prompt from a debug run with the prompt from a live run. Placeholders like <ORDER_NO> and <CUSTOMER_ID> are a classic sign that the model received your instructions but not your transcript, so it wrote a generic sample summary. The audit record will show whether the transcript was really in the live prompt.
• Check userId__c on the live request. When you debug, everything runs as you. In a live transfer, the ownership change is made by routing (the accepting agent, or an automated/system user), so the flow and the prompt template run as that user. Make sure that user has the Prompt Template User permission set and access to everything the template and your Apex read.
• Check that the prompt action's input in the flow is mapped to your Apex output on the path that runs live, not to a variable that only gets populated when you debug.

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

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 @Sourabh Dondekar Good question! Using a dedicated user for Prompt Template execution can help manage access, but it won't directly reduce Flex Credit consumption.

A few suggestions:

1. Flex Credits: Usage depends on billable AI executions, not the number of users.
2. Running User: Record-Triggered Flows don't allow you to directly select a specific running user.
3. Permissions: Make sure the execution context has the required Prompt Template permissions and access.
4. Flow Optimization: Trigger the prompt only when necessary, using entry conditions and field-change checks.
5. Asynchronous Flow: Helps manage processing but doesn't reduce credit consumption by itself.
6. Monitoring: Use Digital Wallet to monitor usage and identify unnecessary executions.

My suggestion: Focus on reducing unnecessary prompt calls rather than restricting users. You can also consider a centralized automation approach for better control.

Hope this helps!

Hello @Caroline Fearey concerning the action, check your API name; it is written " Label the action Translate Survey Input with API name Translate_Survey_Input using any description you’d like". Yours has an extra "Fitness" in it.Eric

@Tugba Salis

your read is correct here - this is a hard limitation, not something that you are missing in the config.  

Standard capability templates have a fixed input defined by the feature that invokes them. Einstein Email Summaries fires against the email itself, so the capability hands the template the email content and nothing else. 

So the way I see it you have two options here:  

Option 1 - you may be able to parse the Case Id from the email text. If your org uses ref ID threading for Email-to-Case, then the case id would be in the email body, and you can use the prompt flow to parse it out.  

Option 2 - build a Flex template instead. Flex templates let you define your own inputs, so you can pass the Case record and use it how you please. You can use this through a quick action / screen flow / agent action / apex - whatever works for you. 

Let me know if that makes sense  

Thanks 

Steve 

Hi chandrika, 

 "Einstein is on" (general Einstein Setup) and the Prompt Template Manager permission set are not the same as the specific toggle that unlocks the Sales Email template type. There's a separate setting you need: 

1. From Setup, search for Einstein for Sales (not the general "Einstein Setup" page) 

2. Find Turn on Sales Emails and set it to True/enabled 

3. Go back to Prompt Builder → New Prompt Template — Sales Email should now appear in the Prompt Template Type dropdown 

This is a distinct feature toggle specific to Sales Cloud's Einstein for Sales add-on, separate from the general Einstein enablement and separate from the Prompt Template Manager permission set (which controls who can build/run templates, not which template types exist in the org). Missing this specific toggle is exactly why Flex, Record Summary, and SDR Qualification show up (those don't depend on it) while Sales Email doesn't. 

Given your Playground expires soon, do this now rather than waiting on a reset — it's a self-service Setup toggle, not something that needs platform-side intervention, so you shouldn't need a fresh Playground at all. 

Reference: