Building Co-Browse and Screen Share Workflows for Complex Technical Support

How-To-Articles
1

Building Co-Browse and Screen Share Workflows for Complex Technical Support

What This Guide Covers

  • You will implement high-fidelity co-browse and screen share capabilities within your digital and voice support channels, allowing agents to see what the customer sees in real-time.
  • You will architect a security-first deployment that utilizes advanced PII (Personally Identifiable Information) masking to ensure sensitive data never leaves the customer’s browser.
  • When complete, your technical support teams will have the tools to resolve complex configuration issues faster, reducing Mean Time to Resolution (MTTR) and eliminating the friction of “verbalizing” screen state.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 2 or CX 3. (Note: CX 1 requires the Digital Add-on).
  • Web Deployment: A functional Genesys Cloud Web Messenger or Legacy Chat deployment.
  • Permissions:
    • Conversation > Co-browse > Control
    • Conversation > Screen-share > View
    • Deployment > Web > View/Edit
  • OAuth Scopes: conversations, webdeployments.
  • Security: Ability to modify your website’s <head> or use a Tag Manager (GTM) to inject the Genesys SDK.

The Implementation Deep-Dive

1. Architectural Choice: Co-Browse vs. Screen Share

The most common architectural error is treating “Co-Browse” and “Screen Share” as synonyms. They are fundamentally different technologies with different security profiles.

The Comparison:

  • Co-Browse: Sends only the DOM (HTML/CSS) to the agent. The agent sees a replica of the webpage. This allows for PII Masking and Element Interaction (the agent can click buttons for the customer). It does NOT require a plugin.
  • Screen Share: Captures the video stream of the entire desktop or a specific application. It is “pixel-based.” It cannot mask individual fields (like a credit card number) and often requires a browser extension or native OS prompt.

Architectural Reasoning: For technical support on a web portal, Co-Browse is the superior choice because it maintains PCI/HIPAA compliance through field masking while providing a smoother, lower-bandwidth experience.

2. Deploying the Co-Browse Script with Security Masking

To enable Co-Browse, you must initialize the Genesys Cloud Web Deployment script with specific configuration for data privacy.

The Step:

  1. In Genesys Cloud, go to Admin > Message > Messenger Deployments.
  2. Enable the Co-browse toggle.
  3. The Critical Part: Define your Masking Rules. You can mask elements by CSS selector (e.g., #credit-card-input) or by class (e.g., .private-data).
  4. On your website, initialize the SDK:
Genesys("subscribe", "CoBrowseService.ready", function() {
  console.log("Co-browse is ready to initiate.");
});

// Example of programmatically starting a session from a custom button
function startSupportSession() {
  Genesys("command", "CoBrowseService.start");
}

[THE TRAP]
Architects often rely on the agent to “ask” for a co-browse session. However, if your website uses a Content Security Policy (CSP), the Co-Browse WebSocket connection may be blocked. You MUST whitelist the Genesys Cloud regional domains (e.g., *.mypurecloud.com) in your connect-src and script-src CSP headers, or the agent will see a blank white screen despite the customer “accepting” the session.

3. Implementing the Voice-to-Co-Browse Handoff

One of the most powerful workflows is starting a Co-Browse session while on a voice call. This requires a Join Code.

The Step:

  1. The customer clicks a “Get Support Code” button on your site.
  2. The website calls Genesys("command", "CoBrowseService.getJoinCode").
  3. The customer reads the 6-digit code to the agent.
  4. The agent enters the code in the Genesys Cloud interaction panel.
  5. Architectural Reasoning: This “side-channel” authentication ensures that the agent is connecting to the correct customer session without needing to find them via an IP address or email search.

4. Advanced Interaction: Remote Control and Annotation

In complex technical support, the agent may need to “take the wheel.”

The Step:

  1. Configure the Control Mode in the Co-browse settings. “View Only” is the default; “Remote Control” must be explicitly enabled and requires a second customer prompt.
  2. During the session, the agent can use the Drawing Tool to circle specific elements on the customer’s screen.
  3. If Remote Control is granted, the agent’s mouse movements are synchronized to the customer’s browser.

[THE TRAP]
Never enable “Remote Control” for pages that contain sensitive configuration settings or “Delete Account” buttons unless you have a strict audit trail. Genesys Cloud records that a Co-Browse session occurred, but it does NOT record the video of the session by default for privacy reasons. Ensure your internal SOPs define exactly when Remote Control is permissible.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Shadow DOM and iFrames

  • The Failure: The agent sees the main page but certain components (like a payment widget or a chat bubble) are invisible or grayed out.
  • The Root Cause: Co-browse cannot cross iFrame boundaries unless the Genesys script is also running inside the iFrame and on the same domain. Elements inside a Shadow DOM may also require specific “piercing” configurations in the Co-browse settings.
  • The Solution: Ensure the Genesys SDK is loaded on all sub-domains and frames where support is required, or avoid using iFrames for critical support workflows.

Edge Case 2: Bandwidth and Latency Spikes

  • The Failure: The agent’s view is “lagging” 10-15 seconds behind the customer’s actions.
  • The Root Cause: While Co-browse is DOM-based, it still sends state updates. High-frequency animations (like a spinning carousel) can saturate the WebSocket with unnecessary updates.
  • The Solution: Use CSS to disable heavy animations when the genesys-cobrowse-active class is present on the <body> tag.

Edge Case 3: Masking Failure in Dynamic SPAs

  • The Failure: A customer enters data into a field that should be masked, but the agent sees it for a split second before it disappears.
  • The Root Cause: In Single Page Applications (React/Vue), elements are often added to the DOM dynamically. If the Co-browse script hasn’t indexed the new element yet, masking might be delayed.
  • The Solution: Use Attribute-based Masking (data-genesys-mask) directly in your component templates rather than relying solely on global CSS selectors. This ensures the element is masked the microsecond it is rendered.

Official References