Communication & Channels

Omnichannel inbox

Handle customer conversations across threads, teams, assignment, mailboxes, and webchat.

Omnichannel inbox

Omnichannel inbox covers the unified conversation workspace for mailboxes, social messages, webchat threads, assignment, agents, and support conversations. 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 unified conversation workspace for mailboxes, social messages, webchat threads, assignment, agents, and support conversations.
  • Where users start: The inbox opens at /omnichannel/home; conversation details use /omnichannel/conversation/:threadId/view.
  • Where administrators configure it: Admins configure mailboxes, user agents, call logs, and omnichannel settings under /omnichannel/settings.
  • Runtime/detail surface: Threads can connect to customers, tickets, webchat sessions, and external integration messages.
  • Platform connections: Omnichannel connects integrations, webchat, tickets, users, notifications, call logs, and customer support operations.

Where it lives

AreaPath or surfaceUse it for
User surfaceThe inbox opens at /omnichannel/home; conversation details use /omnichannel/conversation/:threadId/view.Day-to-day work and review.
ConfigurationAdmins configure mailboxes, user agents, call logs, and omnichannel settings under /omnichannel/settings.Setup, permissions, routing, labels, and behaviour.
Runtime/detailThreads can connect to customers, tickets, webchat sessions, and external integration messages.Testing the live experience users actually see.

Configure it

  1. Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
  2. Open the owning product route: The inbox opens at /omnichannel/home; conversation details use /omnichannel/conversation/:threadId/view.
  3. Review the configuration route and permissions before changing live behaviour: Admins configure mailboxes, user agents, call logs, and omnichannel settings under /omnichannel/settings.
  4. Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
  5. Configure Inbox home, Conversation view, and Mailboxes first because they shape the rest of the rollout.
  6. Add User agents and Webchat only after the core path works with sample data.
  7. Test the runtime surface as a restricted user, not only as a superadmin: Threads can connect to customers, tickets, webchat sessions, and external integration messages.
  8. Check downstream connections after saving: Omnichannel connects integrations, webchat, tickets, users, notifications, call logs, and customer support operations.
  9. Record the owner, rollout date, and support path for the configuration.
  10. Review the first week of activity and remove any option that users do not understand or need.

Configuration options

OptionUse whenNotes
Inbox homeAgents need a queue of conversationsRoute: /omnichannel/home.
Conversation viewAgents need a full threadRoute: /omnichannel/conversation/:threadId/view.
MailboxesEmail channels need routingRoute: /omnichannel/settings/mailboxes.
User agentsWorkload should be assigned to staffRoute: /omnichannel/settings/user-agents.
WebchatWebsite visitors need live chatConfigure in omnichannel settings.
Call logsPhone interactions need classificationRoute: /omnichannel/settings/call-logs.

Operating notes

  • Keep labels aligned with the words users see in the product, especially Inbox home and Conversation view.
  • 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.