Greetings fellow administrators. I am currently troubleshooting a complex routing anomaly affecting our Quality Management division. We have implemented screen recording policies for all voice interactions. However, when an inbound caller is transferred via an Architect flow directly to a dedicated outbound campaign queue, the screen recording fails to initiate for the secondary agent who receives the transferred call. The audio recording functions perfectly, but the video capture remains blank within the interaction evaluation window. I have verified that the Record Screen policy is active for both queues. Does the Architect transfer block somehow strip the screen recording inheritance during queue to queue transfers?
I fight with this outbound routing logic every single day. The issue is not the transfer block. The issue is how the Genesys Cloud media engine classifies the interaction type once it hits the outbound campaign queue.
Even if you transfer an inbound call to an outbound queue, the system strips the standard inbound recording policies because it expects the predictive dialer to manage the media state. You cannot rely on the default queue policies for this scenario.
You must insert a specific Call Recording action into the Architect flow immediately before the transfer block and explicitly set the screen recording parameter to ‘True’.
Eli is totally right. I had to trace this over the network last week for our remote agents. The screen recording client on the agent desktop only triggers when it receives a very specific signaling event from the edge server.
When you bounce the call to the campaign queue, that signaling event never fires because the campaign dialer thinks it is in control. Besides adding the block in Architect, you also need to check your SIP trunk configurations.
If your agents are using WebRTC, make sure the media bypass is disabled, otherwise the screen recording client gets confused about when the media session actually starts.