Designing High-Performance Screen Sharing Workflows for Technical Support Operations

How-To-Articles
1

Designing High-Performance Screen Sharing Workflows for Technical Support Operations

What This Guide Covers

You will configure the WebRTC infrastructure, architect the digital engagement handoff to screen sharing, and implement agent-side security and bandwidth controls. The end result is a low-latency, encrypted screen-sharing session integrated directly into the omnichannel interaction flow with automated fallback mechanisms for network degradation.

Prerequisites, Roles & Licensing

Licensing Requirements

  • Genesys Cloud CX: CX 2 or CX 3 license tier. Screen Sharing requires the Digital Engagement add-on. If you plan to record sessions for quality assurance, you need the Conversation Analytics or Session Recording add-on.
  • NICE CXone: Screen Sharing license. Session Recording license is required if you need persistent storage of the shared media streams.

Permission Strings & OAuth Scopes

  • Genesys Cloud:
    • Digital Engagement > Web Chat > Edit
    • Architect > Flow > Edit
    • OAuth Scopes: digital_engagement:edit, architect:edit, users:read
  • NICE CXone:
    • Telephony > WebRTC > Configure
    • Engagement > Screen Sharing > Manage
    • OAuth Scopes: screen_sharing:manage, studio:edit

External Dependencies

  • STUN/TURN Servers: Public STUN servers are insufficient for enterprise deployments. You must provision private TURN servers (e.g., Twilio Network Traversal Service, AWS Turn, or on-prem coturn) to handle NAT traversal for corporate firewalls.
  • WebRTC Firewall Rules: UDP ports 3478-3481 for signaling and media. TCP fallback ports must be open if UDP is blocked.
  • TLS/SRTP Certificates: Valid certificates for your domain to enforce encrypted media streams.

The Implementation Deep-Dive

1. WebRTC Infrastructure and Network Topology Configuration

Screen sharing relies on WebRTC peer-to-peer connections. In a technical support scenario, the customer is often on an untrusted network (coffee shop, mobile data) while the agent is on a corporate LAN. You must architect the media path to traverse these boundaries without dropping packets.

Architectural Reasoning:
Direct peer-to-peer connections fail when either endpoint sits behind a symmetric NAT or a restrictive firewall. You cannot rely on STUN alone. STUN only reveals the public IP; it does not relay traffic. You must deploy TURN servers to act as a relay when direct connectivity fails. If you skip TURN, you will see a 40% failure rate in screen share initiation for customers on mobile networks or strict corporate proxies.

Configuration Steps:

  1. Provision TURN servers with credentials. Ensure the TURN capacity matches your peak concurrent screen-sharing sessions. A single TURN server instance can handle approximately 1,000 concurrent 1080p streams, but for technical support, you target 720p at 15-24 FPS to reduce bandwidth.
  2. In Genesys Cloud, navigate to Admin > Digital Engagement > Web Chat. Enable Screen Sharing.
  3. Configure the WebRTC settings. Inject your TURN server URI, username, and credential.

The Trap:
The most common misconfiguration is using a single global TURN credential for all users. WebRTC credentials should rotate, and you must set an expiration time. If you use a static credential, an attacker who captures the WebRTC handshake can replay the credential and hijack or inject media into active screen-sharing sessions. Always use dynamic credentials or short-lived tokens.

API Reference: Updating Web Chat Settings with TURN Configuration
Use the PATCH /api/v2/digitalengagement/webchat endpoint to apply TURN settings. Note the webrtc object structure.

PATCH /api/v2/digitalengagement/webchat/{webChatId}
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "webrtc": {
    "enabled": true,
    "screenSharing": {
      "enabled": true,
      "maxBitrate": 2000000,
      "maxFramerate": 24,
      "turnServers": [
        {
          "urls": [
            "turn:turn.example.com:3478?transport=udp",
            "turn:turn.example.com:3478?transport=tcp"
          ],
          "username": "dynamic_user_token",
          "credential": "secure_rotating_credential"
        }
      ]
    }
  }
}

2. Architecting the Digital Engagement Flow

Screen sharing is not a standalone channel; it is a capability within the Web Chat interaction. You must design the Architect flow (Genesys) or Studio flow (CXone) to route screen-sharing requests to queues with agents licensed and equipped for visual support.

Architectural Reasoning:
Technical support agents have a lower concurrent capacity for screen sharing compared to standard chat. Voice agents might handle 1 call. Chat agents might handle 3 chats. Screen-sharing agents should be capped at 1 active session because they require full visual attention and high bandwidth. If you route screen shares to a general chat queue, you will cause agent overload and increased handle time. You need a dedicated routing strategy.

Configuration Steps:

  1. Create a dedicated queue for Technical Support Screen Sharing. Set the Maximum Concurrent Interactions to 1.
  2. Enable Skill-Based Routing for the queue. Add a skill ScreenShare_Tech and assign it only to agents with the appropriate workstation setup (dual monitors, high-speed uplink).
  3. In the Architect flow, add a Web Chat node. Configure the node to detect the screen-sharing request.
  4. Use a Transfer node to route the interaction to the dedicated queue.

The Trap:
Agents often forget to disable their other channels when screen sharing. If an agent is screen sharing and a voice call pops in, the WebRTC stream may drop to free up bandwidth, or the agent desktop may freeze. You must configure the Agent Desktop to pause other channels or set a strict capacity limit. In Genesys, set the user capacity for Digital Engagement to 1 when the ScreenShare skill is active.

Architect JSON Snippet: Web Chat Node with Screen Sharing Logic
This JSON demonstrates a Web Chat node that checks for screen sharing intent and sets an interaction attribute for downstream routing.

{
  "id": "webchat-node-screen-share",
  "type": "webchat",
  "name": "Web Chat - Screen Share Check",
  "properties": {
    "screenSharingEnabled": true,
    "autoAccept": false
  },
  "transitions": {
    "success": {
      "condition": "interaction.screenSharing == true",
      "target": "route-to-tech-queue"
    },
    "failure": {
      "condition": "interaction.screenSharing == false",
      "target": "route-to-general-chat"
    }
  },
  "script": {
    "onScreenShareRequest": "interaction.attributes.screenShareRequested = true;"
  }
}

3. Agent Desktop Integration and Security Controls

The agent experience must enforce security boundaries. Technical support often involves viewing sensitive customer data. You must control who can share, who can view, and who has control over the mouse/keyboard.

Architectural Reasoning:
By default, WebRTC screen sharing can allow the viewer to take control. In a technical support context, you want the agent to have control to troubleshoot, but you must prevent the customer from accidentally or maliciously taking control. You also need to ensure that the screen share is encrypted end-to-end. If you do not enforce SRTP, the media stream can be intercepted on the network path.

Configuration Steps:

  1. In the Agent Desktop settings, enable Screen Sharing Controls.
  2. Set the default permission to Agent Control. This allows the agent to move the mouse and type on the customer’s screen.
  3. Disable Customer Control unless explicitly enabled by a supervisor for training purposes.
  4. Enable Session Recording if you need to audit the support interaction. Note that recording screen shares increases storage costs significantly.

The Trap:
Recording screen shares without redaction can lead to compliance violations (PCI-DSS, HIPAA). If a customer shares a screen containing a credit card number or PII, and you record it, you must ensure the recording is stored in a secure, access-controlled repository. If you are in a regulated industry, you must implement client-side redaction or train agents to blur sensitive areas before sharing. Genesys Cloud does not provide automatic PII redaction for screen shares; you must rely on agent discipline or external middleware.

API Reference: Updating User Capabilities for Screen Sharing
Use the PATCH /api/v2/users/{userId} endpoint to ensure the user has the correct capabilities.

PATCH /api/v2/users/{userId}
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "capabilities": [
    {
      "name": "Digital Engagement",
      "enabled": true
    },
    {
      "name": "Screen Sharing",
      "enabled": true
    }
  ],
  "settings": {
    "screenSharing": {
      "defaultControl": "agent",
      "allowCustomerControl": false,
      "autoRecord": true
    }
  }
}

4. Bandwidth Optimization and Fallback Strategies

Network conditions vary. A customer on 5G has high latency and jitter. An agent on a corporate LAN may have bandwidth throttling. You must design the workflow to degrade gracefully.

Architectural Reasoning:
WebRTC adapts bitrate based on network conditions, but if the connection drops below a threshold, the screen share becomes unusable. You need a fallback strategy. If the screen share fails, the interaction should not die. It should fall back to a standard chat or voice call. You must monitor the WebRTC metrics and trigger a fallback if the quality drops below acceptable levels.

Configuration Steps:

  1. Set the Max Bitrate and Max Framerate in the WebRTC settings. Start with 1080p at 15 FPS.
  2. In the Architect flow, add a Condition node that checks the interaction.qualityMetrics.
  3. If qualityMetrics.jitter > 100 or qualityMetrics.packetLoss > 5%, trigger a fallback.
  4. The fallback can be a Transfer to a voice queue or a Set Interaction Type to standard chat.

The Trap:
Falling back too aggressively causes a poor user experience. If the network fluctuates momentarily, do not drop the screen share. Use a hysteresis threshold. Only trigger the fallback if the quality is poor for more than 10 seconds. You can implement this using a Delay node in Architect before triggering the fallback.

Architect Expression: Quality Check with Hysteresis
This expression checks the quality metrics and triggers a fallback only if the poor quality persists.

// Architect Expression
if (interaction.qualityMetrics.jitter > 100 && interaction.duration > 10000) {
    return "fallback-to-voice";
} else {
    return "continue-screen-share";
}

Validation, Edge Cases & Troubleshooting

Edge Case 1: The Black Screen Syndrome

  • The Failure Condition: The agent accepts the screen share request, but the video window remains black. The customer sees the “Sharing” indicator, but no content appears.
  • The Root Cause: This is almost always a NAT traversal failure. The STUN server cannot establish a direct path, and the TURN server is either misconfigured, unreachable, or out of capacity. Alternatively, the customer’s browser has blocked the screen share permission.
  • The Solution: Check the WebRTC logs in the browser developer tools. Look for ICE connection failures. Verify that the TURN server is responding to the credentials. Ensure the customer has granted screen share permissions in the browser. If using Chrome, check chrome://webrtc-internals for detailed ICE candidate pairs.

Edge Case 2: High Latency and Pixelation Under Load

  • The Failure Condition: The screen share is visible, but the mouse movement is laggy, and text is unreadable due to pixelation.
  • The Root Cause: The bitrate is too high for the network path, or the codec negotiation is suboptimal. WebRTC defaults to VP8 or H.264. If the network has high packet loss, VP8 may struggle. H.264 is more resilient to packet loss but requires decoder support.
  • The Solution: Force the codec to H.264 in the WebRTC settings if VP8 is performing poorly. Reduce the max framerate to 15 FPS. Technical support does not require 30 FPS; 15 FPS is sufficient for reading text and following mouse movements. Adjust the maxBitrate in the WebRTC configuration.

Edge Case 3: Cross-Browser Compatibility (Safari vs Chrome)

  • The Failure Condition: Screen sharing works in Chrome but fails in Safari. The customer sees a permission prompt, but the share does not initiate.
  • The Root Cause: Safari has stricter WebRTC implementations. It may not support certain TURN protocols or codec profiles. Safari also requires explicit user gesture to start screen sharing; you cannot auto-initiate.
  • The Solution: Ensure your WebRTC configuration supports the codecs available in Safari. Safari supports H.264 well. Ensure the TURN server supports TCP fallback, as Safari may prefer TCP over UDP in some network environments. Test the flow in Safari on macOS and iOS.

Official References