- Why does this setting disable the recording_url population in the queue performance view when the conversation detail view confirms successful audio capture?
- The Architect flow is configured for mandatory inbound recording, yet the aggregate metrics report null values for the last 24 hours in the Europe/Paris timezone.
- No API errors are logged, and the storage bucket permissions are verified as correct.
check the recordingSettings object in your queue configuration. specifically, ensure enabled is true and recordType matches the media type you’re querying. if you’re pulling from the performance report but seeing nulls, the issue is likely a mismatch between the recording policy and the view filter. here’s the payload to verify via the API:
POST /api/v2/queues/{queueId}
{
"recordingSettings": {
"enabled": true,
"recordType": "all",
"includeSystemPrompts": true
}
}
verify the queue config matches this. if it does, check the recording field in the conversation details endpoint (/api/v2/conversations/{conversationId}). if that returns a valid URL but the performance report shows null, the problem is in the reporting aggregation logic, not the recording itself. the performance view might be filtering out recordings that don’t meet certain criteria, like duration or status. also, check if the queue has any custom fields that might be overriding the default recording behavior. sometimes, a misconfigured custom field can cause unexpected null values in reports. ensure the timezone settings in the report match the conversation timestamps. if the report is set to Europe/Paris but the conversations are logged in US/Pacific, the data might be filtered out due to timezone mismatches. finally, verify that the reporting interval aligns with the data retention policy. if the data is older than the retention period, it won’t appear in the report. check the retentionSettings in the queue config to ensure recordings are being retained for the expected duration. if all else fails, try regenerating the report or clearing the cache to see if the data populates correctly.
If I remember correctly, the performance view doesn’t aggregate recordings if the recordingSettings object lacks a valid region match. It’s not just about enabled: true. The payload needs to explicitly define the storage region. Check this doc for the exact schema.
The problem here is the recordingSettings object in your queue configuration. it’s not just about enabling the flag. the region mismatch kills the url population in the performance view.
- verify the region match: the storage region in
recordingSettingsmust match the actual bucket location. if you’re in Europe/Paris, it likely needseurope-west-1or similar. - check the recordType: ensure
recordTypealigns with the media type. if it’s set toinboundbut the flow triggersoutboundorfull, the view won’t populate. - validate via API: use the queues API to inspect the current config. this avoids UI caching issues.
const platformClient = require('@genesyscloud/genesyscloud');
async function checkQueueRecordingSettings(queueId) {
const queuesApi = platformClient.QueuesApi;
try {
const queue = await queuesApi.getQueuesQueue(queueId);
console.log('Recording Settings:', JSON.stringify(queue.recordingSettings, null, 2));
// verify region and enabled status
if (!queue.recordingSettings.enabled) {
console.warn('Recording is disabled in queue settings.');
}
if (!queue.recordingSettings.region) {
console.warn('Region is missing. This causes null URLs in performance views.');
}
} catch (error) {
console.error('Failed to fetch queue settings:', error);
}
}
// usage: checkQueueRecordingSettings('your-queue-id-here');
the suggestion above about the region is spot on. i’ve seen this break silently. no errors, just nulls. make sure the enabled flag is true and the recordType isn’t restricting the scope too much. if the flow mandates inbound recording but the queue setting expects full, you’ll get nothing in the aggregate.
also, check the OAuth scopes on the token generating the performance view. it needs analytics:read and recording:read. if the token is limited, the urls won’t resolve even if the data exists.
i’m in PST so it’s late here. hope this helps.
might be worth checking the bulk export metadata directly. the performance view often lags behind the actual storage pointers, especially with cross-region buckets. if the recordingSettings region matches but the URL is still null, the export job might be failing silently on the metadata sync side.