Omni-Channel
Omni-Channel is the routing and presence engine inside Service Cloud that delivers cases, chats, voice calls, messages, and any custom work to the right agent at the right time.
Definition
Omni-Channel is the routing and presence engine inside Service Cloud that delivers cases, chats, voice calls, messages, and any custom work to the right agent at the right time. It tracks each agent's presence (Available, Busy, Offline), their capacity (how many concurrent items they can hold), and their skills (the kinds of work they can handle). When a new work item arrives, Omni-Channel runs a routing algorithm against the available agent pool and pushes the work to the best match. The agent accepts or rejects, the system records the response time, and the work appears in the Service Console.
Omni-Channel replaces older single-channel routing (Live Agent for chat, separate queues for cases) with a unified routing layer. It runs through three concepts: Service Channels (a definition of a kind of work, like Cases or Chats), Routing Configurations (how the work is routed: skill-based, least-active, most-available), and Presence Configurations (what counts as available and at what capacity). Together they let a Service Cloud team route incoming work intelligently across hundreds of agents without manual queue cherry-picking. Omni-Channel is the difference between a queue-based call center model and a modern routed contact center.
How Omni-Channel routes work across an agent team
Service Channels: defining the kinds of work
A Service Channel is a Salesforce object that defines a category of routable work. The standard Service Channels are Cases, Chats, Live Messages, Voice Calls. Custom Service Channels can be defined for any custom object: a Custom Channel for Support Ticket records, a Custom Channel for Approval Requests. Each Service Channel ties to a sObject and a routing model. The Routing Model is either Push (the system assigns the work and the agent accepts) or Pull (the work sits in a queue and agents claim it). Push is the default for most modern setups. Pull mirrors the older queue-cherry-pick model and is now mostly used for low-priority backlog work.
Routing Configurations: how matches happen
A Routing Configuration tells Omni-Channel how to match work to agents. The Routing Model can be Least Active (assigns to the agent with the fewest currently active items), Most Available (assigns to the agent with the most spare capacity), or External Routing (Omni-Channel hands off to an external system like Genesys or Five9). The Push Time Out defines how long an agent has to accept before the system re-routes. The Reroute and Decline behaviors define what happens on rejection. Each Service Channel uses a Routing Configuration, which means different work types can have different match algorithms in the same org.
Presence Configurations and capacity
A Presence Configuration is the agent-side counterpart to Routing. It defines the Capacity (how many concurrent items the agent can hold, weighted by work type), the Auto-Accept setting (whether the agent has to manually accept work), and the Idle timeout. Capacity is the key knob. A senior agent might have capacity 4 (two cases, one chat, one call simultaneously). A trainee might have capacity 1. The work types are weighted: a chat might cost 1 unit of capacity, a case 2 units. The Presence Configuration is assigned per profile or per user.
Skills-Based Routing
On top of the basic Service Channel and Routing Configuration, Skills-Based Routing layers explicit skill matching. An agent has skills (Spanish, Refunds, Enterprise Accounts) defined on their user record. A case has Required Skills (Spanish, Refunds) set either manually or by Flow at case creation. Omni-Channel matches the case to an agent whose skill set covers all required skills, with capacity available. Skills are the difference between "any agent who is free" and "the right agent for this customer". For multilingual support teams, Skills-Based Routing is non-negotiable.
The Omni-Channel widget in the Utility Bar
Agents interact with Omni-Channel through the widget in the Utility Bar of the Service Console. The widget shows the agent's current presence status, the list of currently held work items, and notifications for new work. When work is pushed, the widget plays a sound, surfaces the work details (case number, priority, brief description), and offers Accept/Reject buttons. Once accepted, the work item opens as a new console tab automatically. Once completed, the agent clicks Close Work and the system marks the item complete. The whole loop runs without leaving the console.
Status changes and the agent presence model
Presence statuses are configurable. Beyond the defaults (Online, Offline), most orgs add Lunch, Training, Break, After Call Work. Each status has a category (Available, Busy, Offline) that determines whether the system routes work to the agent while in that status. Agents change their status manually through the widget. The platform tracks the history of presence changes in the UserServicePresence object, which is queryable through SOQL for workforce-management reporting. The most common metric this enables: "what percent of the workday is the agent in an Available state".
Reporting on Omni-Channel: queue dwell, time to accept, abandonment
Omni-Channel exposes operational metrics through several report types. AgentWork is the record of every work item assignment (which agent got which item, how long they held it). PendingServiceRouting is the queue snapshot (what is waiting, for how long). UserServicePresence is the presence history. Custom reports built on these objects answer the core contact-center questions: average queue dwell time, time to accept, abandon rate, agent utilization. Most enterprise Service Cloud deployments build a workforce-management dashboard on top of these objects in CRM Analytics.
Configuring Omni-Channel for a contact center
Setting up Omni-Channel is a multi-step Setup workflow: enable the feature, define Service Channels, build Routing Configurations, build Presence Configurations, add the Omni-Channel widget to the Service Console Utility Bar, and assign users.
- Enable Omni-Channel
Setup, Omni-Channel Settings, Enable Omni-Channel. The flag is org-level. Without it, Service Channels and Presence Configurations cannot be created.
- Create Service Channels
Setup, Service Channels, New. Define one for each kind of routed work: Cases, Chats, Voice Calls, Messages, Custom Work. Pick the sObject and the Routing Type (Most Available, Least Active, External).
- Build Routing Configurations
Setup, Routing Configurations, New. Set the Routing Model, Push Time Out (typically 30 seconds), and Auto-Accept setting. Higher Push Time Out reduces stress; lower gives faster routing.
- Build Presence Configurations
Setup, Presence Configurations, New. Set Capacity, Auto-Accept, Decline Reasons, Idle Time. Assign each agent type to a Presence Configuration matching their training level.
- Configure work type capacity
Inside the Presence Configuration, set the per-Service-Channel capacity weight. A chat might cost 1 unit, a case 2 units. The weights cap concurrency on the agent.
- Add the Omni-Channel widget to the Service Console
Setup, App Manager, edit the Service Console, Utility Bar, add Omni-Channel. The widget renders at the bottom of the console for assigned agents.
- Assign Skills if using Skills-Based Routing
Setup, Skills, New, define each Skill (Spanish, Refunds, Tier 2). Assign Skills to users on their user record. Configure Required Skills on cases through Flow at case creation.
- Train agents on the presence and accept flow
Agents need to know how to change status, accept work, decline with reason, and close work. A 30-minute training prevents the most common "Omni isn't sending me anything" complaints (the agent is in Offline status without realizing).
The category of routable work (Cases, Chats, Voice, custom). Ties to a sObject and a Routing Configuration.
How work is matched to agents: Most Available, Least Active, External Routing. Includes Push Time Out and Reroute behaviors.
Per-agent capacity, accept behavior, and presence rules. Assigned per profile or per user.
Per-Service-Channel weight against the agent capacity. A chat might be 1 unit; a case might be 2 units. Caps concurrent work.
Optional layer matching agent skills (Spanish, Refunds) against required skills on the work item.
How long an agent has to accept routed work before the system re-routes. Typical value 30-60 seconds.
- Capacity weights are the most-misconfigured Omni-Channel knob. Wrong weights cause either over-loaded agents or under-utilized agents. Tune in pilot, monitor weekly.
- An agent in Offline status receives no routed work. Many "Omni is broken" tickets trace to the agent's presence widget being collapsed and the agent not realizing they are Offline.
- Skills-Based Routing requires Required Skills on every routed work item. A case without Required Skills routes through the basic Service Channel rules. Flow at case creation is the right place to set Required Skills.
- Push Time Out below 20 seconds creates agent stress and increases the rejection rate. Below 15 seconds is hostile. Most teams settle at 30-60 seconds.
- External Routing integrations (Genesys, Five9, NICE) require Connected App credentials and a partner-built adapter. Plan the integration as a separate project from the Omni-Channel base configuration.
Trust & references
Straight from the source - Salesforce's reference material on Omni-Channel.
- Omni-Channel OverviewSalesforce Help
- Routing ConfigurationsSalesforce Help
- Skills-Based RoutingSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What business function does Omni-Channel primarily support?
Q2. Which Salesforce Cloud includes Omni-Channel as a key feature?
Q3. How does Omni-Channel help support agents be more productive?
Discussion
Loading discussion…