Communication & Channels
Webchat
Configure and embed the public webchat widget for customer support.
Webchat
Webchat covers the embeddable website chat widget that routes public visitor conversations into Omnichannel. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: the embeddable website chat widget that routes public visitor conversations into Omnichannel.
- Where users start: Webchat settings are part of Omnichannel settings and save into the omnichannel settings record.
- Where administrators configure it: Settings include enabled state, auth mode, brand name, welcome message, launcher label, primary colour, and mailbox ID.
- Runtime/detail surface: The public widget is embedded on an external site and creates conversations for agents in
/omnichannel/home. - Platform connections: Webchat connects public access, widgets, Omnichannel mailboxes, notifications, customer support, and embed code.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Webchat settings are part of Omnichannel settings and save into the omnichannel settings record. | Day-to-day work and review. |
| Configuration | Settings include enabled state, auth mode, brand name, welcome message, launcher label, primary colour, and mailbox ID. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | The public widget is embedded on an external site and creates conversations for agents in /omnichannel/home. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Webchat settings are part of Omnichannel settings and save into the omnichannel settings record.
- Review the configuration route and permissions before changing live behaviour: Settings include enabled state, auth mode, brand name, welcome message, launcher label, primary colour, and mailbox ID.
- Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Enabled, Auth mode, and Brand name first because they shape the rest of the rollout.
- Add Welcome message and Launcher label only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: The public widget is embedded on an external site and creates conversations for agents in
/omnichannel/home. - Check downstream connections after saving: Webchat connects public access, widgets, Omnichannel mailboxes, notifications, customer support, and embed code.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Enabled | The launcher should appear on the website | Keep disabled until routing is tested. |
| Auth mode | Visitors may be anonymous or verified | Choose based on support policy. |
| Brand name | Widget should match the public site | Use customer-facing language. |
| Welcome message | Visitors need a prompt | Keep it short and specific. |
| Launcher label | Button text should invite action | Default is “Chat with us”. |
| Mailbox | Conversations need a destination | Choose an Omnichannel mailbox. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Enabled and Auth mode.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.