Architecting Point-of-Sale Terminal Support Workflows with Remote Screen Sharing Capability

How-To-Articles
1

Architecting Point-of-Sale Terminal Support Workflows with Remote Screen Sharing Capability

What This Guide Covers

This guide details the architectural design and implementation of a secure remote support workflow for Point-of-Sale (POS) terminal assistance within Genesys Cloud CX. You will configure a unified agent workflow that combines voice interaction with secure, read-only remote desktop viewing capabilities using the Genesys Cloud Remote Support feature. The end result is a resilient, audit-compliant support channel that allows agents to visually diagnose hardware or software issues on customer devices without requiring third-party VNC or RDP tools, ensuring data privacy and regulatory adherence.

Prerequisites, Roles & Licensing

Licensing Requirements

  • Genesys Cloud CX License: Minimum CX 2 tier is required for access to the Remote Support feature. CX 1 licenses do not include the necessary media handling capabilities for remote desktop streaming.
  • Add-ons: No specific WEM or WFM add-on is strictly required for the core functionality, but WEM is recommended if you need to capture the remote session video for quality assurance scoring.

Permissions & Roles

To implement this architecture, the provisioning account must hold the following granular permissions:

  • Telephony > Trunk > Edit (For configuring inbound/outbound routing if SIP trunks are involved)
  • Architecture > Flow > Edit (To create the IVR and Interaction flows)
  • Administration > User > Edit (To assign the Remote Support Provider role to agents)
  • Remote Support > Session > Manage (To enable the feature at the organization level)

External Dependencies

  • Customer Browser: The customer must access the support portal via a modern HTML5-compliant browser (Chrome, Edge, Firefox, Safari). Legacy POS terminals with outdated embedded browsers may require a kiosk mode configuration or a dedicated support app.
  • Firewall/Proxy: Outbound HTTPS traffic (port 443) must be allowed from the POS terminal to *.mypurecloud.com and *.genesys.com domains. Strict corporate firewalls often block WebSocket connections required for the remote desktop stream.

The Implementation Deep-Dive

1. Enabling Remote Support at the Organization Level

Before any flow logic can be constructed, the platform capability must be unlocked. This is a global toggle that affects all users with the appropriate license.

Configuration Steps:

  1. Navigate to Admin > Features > Remote Support.
  2. Set Remote Support to Enabled.
  3. Configure the Session Timeout. For POS environments, set this to 15 minutes. POS transactions are time-sensitive; long idle sessions increase security risk and resource consumption.
  4. Enable Require Consent. This is non-negotiable for compliance. It forces the customer to explicitly accept the screen sharing request before the agent can view the display.

The Trap: Ignoring WebSocket Persistence
A common misconfiguration is enabling the feature but failing to validate the WebSocket connection from the customer endpoint. Genesys Cloud Remote Support relies on a persistent WebSocket connection for the screen stream. If the POS terminal is behind a strict reverse proxy that terminates idle connections after 60 seconds, the video stream will fail to initialize.

  • The Fix: Ensure your load balancers or reverse proxies (e.g., NGINX, F5) have proxy_read_timeout and proxy_send_timeout set to at least 3600 seconds for traffic destined for Genesys Cloud domains.

Architectural Reasoning:
We enable global consent because POS terminals often operate in public-facing retail environments. Unauthorized screen capture violates PCI-DSS guidelines regarding cardholder data visibility. By forcing explicit consent, we create an auditable log entry (RemoteSupportSessionCreated) that proves the customer authorized the visual access, which is critical during fraud investigations.

2. Designing the Unified Interaction Flow

The core of this solution is a single Interaction Flow that handles both the voice conversation and the remote support session. We do not use separate flows because context switching breaks the agent’s workflow and complicates analytics.

Flow Logic Overview:

  1. Inbound Call/Chat: The customer initiates contact via Voice or Web Chat.
  2. Authentication: Verify the POS terminal ID or Store ID via IVR or Chat prompt.
  3. Queue Routing: Route to a specialized “POS Support” queue.
  4. Agent Engagement: The agent answers.
  5. Conditional Trigger: The agent clicks a “Initiate Remote Support” button in the Interaction Dashboard.
  6. Customer Prompt: The customer receives a secure link to launch the remote viewer.
  7. Session Establishment: The agent views the POS screen.

The Trap: Using “Wait” Blocks for Remote Support Initiation
Novice architects often insert a Wait block in the flow, expecting the system to pause the flow while the agent initiates remote support. This is incorrect. The Remote Support feature is agent-initiated, not flow-initiated. If you pause the flow, the interaction may timeout if the agent takes too long.

  • The Fix: Do not block the flow. Instead, use a Set Variable block to flag remote_support_requested = true. The flow should proceed to the “Wrap-up” or “Post-Interaction” logic only after the agent manually closes the remote session. The flow remains active in the background, keeping the voice/chat channel open.

Architectural Reasoning:
We keep the flow active because the voice channel serves as the primary coordination medium. The agent says, “I am seeing your screen now,” while the customer points to a specific error code. If the flow terminates, the agent loses the ability to transfer the call if the issue requires escalation to L2 hardware support.

3. Configuring the Agent Workspace for POS Support

Agents need a streamlined interface. The default Interaction Dashboard can be cluttered. We configure the Remote Support widget to be prominent.

Configuration Steps:

  1. Navigate to Admin > User Settings > UI Settings.
  2. Locate the Remote Support widget.
  3. Set Default Visibility to Visible.
  4. Configure Quick Actions to include “Start Remote Session” and “End Remote Session”.

The Trap: Granting Write/Control Permissions
By default, Remote Support can be configured to allow “View Only” or “View and Control.” For POS terminals, always select “View Only”.

  • The Catastrophic Effect: If an agent has “Control” permissions, they can click buttons on the POS screen. If they accidentally trigger a “Refund” or “Void Transaction” command, they are liable for financial loss. Furthermore, PCI-DSS strictly prohibits remote control of systems processing card data unless explicitly authorized and logged by a dedicated, restricted tool. Genesys Remote Support is not PCI-certified for control of card data entry fields.
  • The Fix: In the Remote Support settings, set the global default to View Only. Override this only for internal IT helpdesk queues, never for external customer-facing POS support.

4. Implementing Secure Link Generation

The customer must receive the remote support link securely. We avoid sending this via SMS (which can be intercepted) or email (which may land in spam). Instead, we inject it into the active Chat session or display it on a secure IVR screen.

API Payload for Link Generation:
While the UI handles this, understanding the underlying API helps in troubleshooting. When the agent clicks “Start,” the platform generates a token.

POST /api/v2/remotesupport/sessions

{
  "userId": "agent-user-id-here",
  "interactionId": "current-interaction-id",
  "type": "view",
  "consentRequired": true
}

Response:

{
  "id": "session-id-123",
  "url": "https://mysite.mypurecloud.com/remotesupport/launch?token=xyz",
  "status": "pending"
}

The Trap: Token Expiration Mismatch
The generated link has a short TTL (Time To Live), typically 5 minutes. If the customer delays clicking the link, the token expires.

  • The Solution: In the IVR or Chat script, instruct the customer to “Click the link immediately.” If the link expires, the agent must click “Start” again to generate a new token. Do not try to cache the URL in a variable; it becomes invalid.

Architectural Reasoning:
We use the Interaction ID to bind the remote session to the specific voice/chat conversation. This ensures that if the agent transfers the call, the remote session context is preserved (or cleanly terminated) based on the transfer rules. It also allows us to link the remote session logs to the specific interaction record for QA purposes.

5. Handling Network Constraints on POS Terminals

POS terminals often operate on restricted corporate networks with limited bandwidth. The remote desktop stream uses WebRTC, which is sensitive to packet loss.

Optimization Steps:

  1. In the Remote Support settings, enable Adaptive Bitrate. This allows the stream to degrade gracefully (lower resolution) if bandwidth drops, rather than freezing completely.
  2. Configure the Max Frame Rate to 15 FPS. POS screens are largely static (menus, receipts). High frame rates (30/60 FPS) waste bandwidth and battery on tablet-based POS systems without adding diagnostic value.

The Trap: Ignoring Camera Permissions
Some POS tablets have front-facing cameras. The Remote Support SDK requests camera access for “screen mirroring” in some Android/iOS implementations. If the POS OS blocks this permission, the stream fails.

  • The Fix: Work with the POS device manufacturer to ensure the Genesys Cloud domain is whitelisted for camera/screen capture permissions in the device management policy (MDM).

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Black Screen” Phenomenon

The Failure Condition:
The agent clicks “Start,” the customer accepts the consent, but the agent sees a black screen with the message “Waiting for stream.”

The Root Cause:
This is almost always a WebSocket or WebRTC firewall issue. The POS terminal can reach the Genesys Cloud signaling server, but the peer-to-peer (or relayed) media path is blocked. Specifically, the UDP ports required for WebRTC are being dropped by the corporate firewall.

The Solution:

  1. Verify that the POS terminal can resolve and connect to *.turn.mypurecloud.com on UDP ports 3478 and 5349.
  2. If UDP is blocked, Genesys Cloud falls back to TCP relay, which is slower and more prone to latency. If TCP is also blocked, the stream fails.
  3. Immediate Workaround: Ask the customer to connect their POS tablet to a mobile hotspot (if policy allows) to bypass the corporate firewall. This isolates the issue to the network.
  4. Permanent Fix: Open UDP ports 1024-65535 outbound to Genesys Cloud IPs for the POS VLAN.

Edge Case 2: PCI-DSS Compliance and Data Masking

The Failure Condition:
An auditor flags that credit card numbers are visible on the POS screen during the remote session. Even though the agent is only “Viewing,” the stream contains sensitive data.

The Root Cause:
Standard Remote Support streams the entire desktop buffer. It does not have built-in OCR or pixel-level masking for specific UI elements.

The Solution:

  1. Policy Enforcement: Create a strict SOP (Standard Operating Procedure) that agents must instruct the customer to “blur” or “cover” sensitive fields before accepting the remote session.
  2. Technical Mitigation: If the POS software supports it, configure a “Privacy Mode” or “Kiosk Mode” that hides transaction details during support calls.
  3. Recording: Ensure that Remote Support Sessions are not recorded by default in WEM. If recording is enabled, the video file contains PII/PCI data. You must configure WEM to exclude remote support media from automatic recording or apply heavy redaction rules.

Architectural Reasoning:
We rely on procedural controls because technical masking is complex and error-prone. The “View Only” mode is a control, but it is not a guarantee of privacy. The burden of proof lies with the organization to ensure that sensitive data is not exposed.

Edge Case 3: Session Desynchronization

The Failure Condition:
The agent sees the POS screen frozen, but the customer claims they are scrolling. The voice channel remains active.

The Root Cause:
The WebSocket connection for the screen stream has timed out, but the signaling channel remains open. This often happens on high-latency international connections.

The Solution:

  1. Implement a Heartbeat Check in the Architect Flow (if using a custom wrapper) or rely on the built-in timeout.
  2. Instruct the agent to “Refresh the Remote Session.” This terminates the current WebSocket and establishes a new one.
  3. If the issue persists, switch to Photo Mode. The customer takes a screenshot and uploads it to the chat. This is a lower-bandwidth fallback that works even when the live stream fails.

Official References