Widgets — Web Chat & Web Messenger Topic Detail Navigation (Web Messenger) Admin → Message → Messenger Configurations and Messenger Deployments Navigation (Web Chat v2) Admin → Contact Center → Widgets Purpose Provide a chat interface on websites connecting customers to Genesys Cloud agents Modern Standard Web Messenger — persistent, asynchronous Legacy Web Chat v2 — session-based Web Messenger (Modern Standard) Web Messenger offers a persistent, asynchronous experience — customers can leave the website and return later with their full conversation history still intact. Component Description Messenger Configurations Defines look and feel — color palette, logo, features (file uploads, emojis, read receipts) Messenger Deployments Links a Messenger Configuration to an Architect Inbound Message Flow — this is where routing is assigned Deployment Snippet JavaScript code pasted into the website or to render the chat icon Deployment ID Unique GUID identifying which configuration the website loads Allowed Domains Security whitelist — only URLs listed here can render the widget Web Chat v2 (Legacy) Strictly session-based — if the customer refreshes or closes the browser tab, the chat session is lost. Widget Type Description Standard Simple chat window provided by Genesys Third-Party Uses Genesys as the routing engine while a completely custom UI is built by developers Widget Features Both versions support the following controls: Feature Description File Uploads Enable/disable customer ability to send images or documents Typing Indicators Shows when the agent or customer is typing Read Receipts Informs users when messages have been seen Guest Chat Allows unauthenticated chat, or require login to pull CRM data automatically Pre-Chat Form Collects Name, Email, Account Number before routing — data passed into Architect flow for intelligent routing Routing Logic Widgets do not send chats directly to agents. They route to an Architect Inbound Message Flow first. The flow processes pre-chat form data and routes to the correct queue. Customer Clicks Chat Widget ↓ Pre-Chat Form (Name, Email, Account Number) ↓ Architect Inbound Message Flow ↓ Data Evaluated / Customer Identified ↓ Transfer to Queue ↓ Agent Deployment Steps (Web Messenger) Navigate to Admin → Message → Messenger Configurations Create a configuration — set branding, colors, features Navigate to Admin → Message → Messenger Deployments Create a deployment — link configuration to an Architect Inbound Message Flow Add Allowed Domains (whitelist your website URLs) Copy the Deployment Snippet (JavaScript) Paste the snippet into the website's or Connect to a chat flow: Deployment key generated: Technical Reference Component Detail Snippet JavaScript placed in or of the website Deployment ID Unique GUID — identifies which configuration loads Allowed Domains Must whitelist all URLs where the widget appears Persistence Web Messenger supports Persistent or Clearing Conversation session modes Web Messenger vs. Web Chat v2 Feature Web Messenger Web Chat v2 Session type Persistent / asynchronous Session-based (lost on refresh) Conversation history Retained across sessions Lost when session ends Routing Architect Inbound Message Flow Architect Inbound Chat Flow Status Current standard Legacy — still supported Customization Full branding via Messenger Config Limited Interview Cheat Sheet Question Answer What is the modern widget standard? Web Messenger — persistent and asynchronous What happens to a Web Chat v2 session on page refresh? The session is lost What does the Deployment ID identify? Which Messenger Configuration loads on the website What must be configured for security? Allowed Domains whitelist Where does the widget route interactions? To an Architect Inbound Message Flow, not directly to agents What is a Pre-Chat Form used for? Collecting customer data before routing for intelligent queue assignment