Screen Recording Retention Policy vs. Performance Dashboard Availability

  • Genesys Cloud Environment: Europe/Paris
  • Role: Platform Operations / Architect
  • Feature: Screen Recording & Performance Dashboards
  • Issue: Data availability lag in reporting views

Stuck on reconciling the expected data availability of screen recordings within the Performance Dashboard against our configured retention policies.

Our organization mandates a 30-day retention period for all agent desktop recordings to comply with internal audit standards. However, when filtering the ‘Agent Performance’ view by ‘Screen Recordings’ in the last 72 hours, several agents show zero recordings despite confirmed activity logs in the Conversation Detail View.

The recordings themselves are accessible via the manual ‘Recordings’ tab, indicating storage is successful. The discrepancy appears isolated to the aggregated metrics displayed in the standard Performance Dashboard widgets.

Is there a known synchronization delay between the raw recording storage layer and the Performance Dashboard aggregation engine? Or does the dashboard require a specific configuration toggle to include recordings that are still within the ‘processing’ state before the 30-day retention window closes?

We require these metrics for real-time supervisor oversight, so understanding the latency or configuration gap is critical. Any insights into the data pipeline for screen recording metrics would be appreciated.

The root of the issue is that the Performance Dashboard aggregates data from the analytics engine, which operates on a separate ingestion pipeline from the media storage service handling screen recordings. This architectural decoupling means that even with a 30-day retention policy, the metadata required for dashboard visualization is not immediately available upon recording completion. The system typically requires a 24-48 hour window for the analytics index to fully reconcile the media file existence with the agent session logs. If you are seeing gaps or missing data, it is likely due to the asynchronous nature of this reconciliation process rather than a retention policy conflict. To verify the actual status of the recordings and force a manual refresh if necessary, you can query the Genesys Cloud Analytics API directly. This bypasses the cached dashboard view and provides real-time status on the ingestion job.

GET /api/v2/analytics/interactions/summary?dateFrom=2023-10-01T00:00:00.000Z&dateTo=2023-10-31T23:59:59.999Z&filter=type:eq:screenrecording

Ensure that the filter parameter strictly matches the interaction type for screen recordings. If the API returns null or incomplete data, check the “Recording” section in the Admin Console under “Data Retention” to confirm that the “Analytics” checkbox is enabled for screen recordings. Disabling this checkbox will prevent the data from ever reaching the Performance Dashboard, regardless of the retention period. Additionally, verify that the user account accessing the dashboard has the “View Reports” permission enabled for the specific queue or group where the recordings are generated. Misconfigured permissions can mimic data lag by hiding valid records from the view.

The root of the issue is that the performance dashboard relies on the analytics index, which has a separate ingestion pipeline from the media storage service. This architectural decoupling means metadata is not immediately available upon recording completion. The system typically requires a 24-48 hour window for the analytics engine to fully reconcile the media file existence with the reporting views. This delay is standard behavior and not a configuration error.

For load testing scenarios, this lag can impact validation if you are checking real-time availability. A common fix is to verify the recording status via the API directly before expecting it in the dashboard. You can use the GET /api/v2/recordings/{recordingId} endpoint to check the status field. If it returns “COMPLETED”, the file is stored, but the dashboard may still be processing the metadata.

Here is a simple JMeter request to validate the recording status programmatically during your tests:

GET /api/v2/recordings/{recordingId}
Headers:
 Authorization: Bearer {{access_token}}
 Content-Type: application/json

Check the response body for "status": "COMPLETED". If the status is completed but the dashboard is empty, wait for the analytics batch process to run. This usually happens overnight.

Also, ensure your retention policy is correctly set in the Admin console under Organization Settings > Recordings. A 30-day retention is standard, but verify that the “Delete recordings after” setting is not overriding the analytics retention. Sometimes, if the media is deleted before the analytics index is fully built, the dashboard entry disappears entirely.

Note: Do not rely on the Performance Dashboard for real-time verification of screen recordings. Use the API or the Call Search tool for immediate status checks. The dashboard is for historical analysis, not instant operational verification.