Data 360
GenAIGatewayRequest: why your AI usage counts look wrong
Understand Salesforce AI audit records, find missing requests, and avoid counting one model request several times when you join responses and feedback.
One AI request can become four rows in a reporting query. If your usage chart counts those rows, it overstates how many requests Salesforce processed.
GenAIGatewayRequest belongs to Salesforce’s generative AI audit model in Data 360. Start there when tracing a model request, then follow its related responses and feedback. Before building a dashboard, decide what each row in your query represents.
Find one known request first
If the query is empty, make a test interaction and note its time and user. Check that audit collection is active and that you’re looking in the configured data space.
Salesforce’s setup guide calls the page Einstein Audit, Analytics, and Monitoring Setup. It documents automatic enablement for an org with a single data space when Agentforce is enabled. Check the actual setting in your org, especially if it has multiple data spaces.
The guide allows up to 24 hours for initial data to appear, with hourly refreshes afterward. Collection can also be suspended, leaving a gap while older records remain. Check that history before interpreting an empty period as a drop in usage.
Find the raw test request before adding joins or feature filters. You’ll then have a record to check each change against.
Check whether your query uses the legacy model
Salesforce recommends standard audit DMOs for new reporting. Older examples use legacy custom DMOs, including the name GenAIGatewayRequest. The mapping guide pairs that with the standard Ai Gateway Request object.
Open the DMO in your org and inspect its actual API name, identifier, timestamp, and relationship fields. Don’t treat the display name in an article as a queryable API name. Salesforce also publishes a request object reference for comparison.
If you’re replacing an existing dashboard, compare the old and new queries over the same time window and sample requests. Combining legacy and standard records without checking how they correspond can count the same interaction twice.
Separate requests from feedback events
Suppose one request produces two generations, and each generation receives two feedback events. Joining them can produce four rows with the same request identifier. The Salesforce audit-model walkthrough explains these one-to-many relationships.
For a request-level usage report:
- Count distinct request identifiers within the intended org and time window.
- Calculate request-level token totals before joining feedback. Otherwise the same total can appear on several rows and be summed repeatedly.
- Reduce child records to one row per request before joining them back. For example, a simple “received feedback” flag doesn’t need every feedback comment in the usage query.
Keep generation counts and feedback-event counts as separate measures. When calculating an acceptance rate, state whether the denominator is feedback events, responses with feedback, or all responses. A missing rating doesn’t tell you that someone accepted the answer.
Check a few requests manually, including one with no feedback. An inner join can exclude that request entirely and make a correct-looking count incomplete.
Look for overflow tags if a trace is missing
Salesforce’s analytics guide documents a default limit of 20 ordinary tag rows per request, with reserved planner tags handled separately. Additional tags are stored as JSON in a REMAINDER_TAGS row.
If your query expects one row per tag, it may miss a trace or feature identifier stored in that JSON. Check both forms, extract the values you need, and deduplicate request identifiers before counting them.
Decide who needs to see the original text
The audit model can contain resolved prompts and generated responses. An adoption report usually needs counts, dates, and feature labels. Investigating an incorrect answer may require the original text, which deserves more restricted access.
Salesforce’s Audit and Feedback overview describes controls including dynamic masking and field-specific exclusions. Apply the controls supported by your deployment and test them with the intended users.
A request count also isn’t a count of conversations or resolved cases. One conversation may invoke the model several times. Use the conversation records when that is the question you’re trying to answer, and keep the model-usage chart labelled accordingly.
