Why does this config cause a complete failure to link screen recording metadata with the corresponding voice interaction when migrating from Zendesk Talk to Genesys Cloud? We are currently in the final testing phase of moving a mid-sized support team from Zendesk to Genesys Cloud, and the screen recording feature is causing significant headaches. In Zendesk, screen shares were automatically bundled with the ticket thread, creating a single source of truth. Here, we are trying to replicate that seamless experience using the Genesys Cloud Screen Recording API and Architect flows, but the correlation is failing.
The issue arises when agents initiate a screen share via the Genesys Cloud desktop application (version 2023.11.0) while on a voice call routed through a BYOC trunk. The recording starts successfully, and we can see the file appear in the Admin console under Recordings. However, when we query the /api/v2/recordings endpoint using the interaction ID from the voice call, the response returns an empty list for screen recordings. The voice recording links perfectly, but the screen share is orphaned.
We have verified that the “Record screen” checkbox is enabled in the Architect flow under the “Start Screen Recording” block, and the permissions for the agent role include recording:view and recording:read. The error log in the browser console shows a 404 Not Found when the desktop app attempts to fetch the recording status via GET /api/v2/recordings/screen/{recordingId}.
Is there a specific configuration in the Genesys Cloud Admin settings that forces screen recordings to be treated as separate interactions rather than child resources of the voice call? In Zendesk, we never had to worry about linking IDs manually. We need a way to ensure the screen recording is tagged with the same interactionId as the voice call so our reporting dashboard can display them together. Any advice on configuring the Architect flow or API payloads to fix this linkage would be greatly appreciated.