Omni-Channel is the Service Cloud engine that pushes work to reps instead of letting them pick it from a list. Each case, messaging session or call enters a queue, and Omni-Channel offers it to an available rep with spare capacity, either anyone in that queue (queue-based routing) or only reps holding the right skills (skills-based routing). Get three settings right and it works: how much each rep can handle, which presence statuses they can choose, and which work goes first.
The moving parts
Omni-Channel is configured from a handful of records that reference each other, and most routing problems trace back to one of them being set up in isolation. Before changing anything, it helps to know what each one controls:
- Service channels declare which kinds of work Omni-Channel may route, such as cases, messaging sessions, voice calls, leads or a custom object.
- Queues hold the work waiting to be assigned and determine which reps are eligible for it.
- Routing configurations, attached to queues, set the priority of that queue, the routing model and how much capacity each item consumes.
- Presence statuses are what reps choose in the Omni-Channel widget, and each one lists the channels a rep accepts work from while in it.
- Presence configurations assign capacity and related behavior to specific users or profiles.
- Skills and service resources describe what each rep can handle, used only when you route by skill.
Within a routing configuration, Most Available sends work to the rep with the most spare capacity, while Least Active favors the rep with the fewest items in progress. Omni-Channel serves higher-priority queues first and, within a queue, the oldest items first, so priority is a business decision rather than a technical default.
Queue-based versus skills-based routing
| Queue-based routing | Skills-based routing | |
|---|---|---|
| How a rep qualifies | Membership in the queue | Holding every required skill, optionally at a minimum level |
| What you maintain | Queue membership | A skill list per rep plus rules that map case fields to skills |
| Best for | Teams organized by product line, region or tier, where any member can take any item | Blended teams where language, product certification or specialty cuts across groups |
| Main risk | Queue sprawl as every combination gets its own queue | Work waiting with no matching rep online because skill data is incomplete |
| Where it breaks down | Dozens of overlapping queues that reps join by habit | Case fields that are blank or wrong at creation, so skills cannot be derived |
Skills are attached in two ways. Skills-based routing rules, the feature once called attribute-based routing, map field values to skills without code: a case type of Product Return can require a Returns Processing skill. For more involved logic, an Omni-Channel flow can calculate the required skills and pass them to the Route Work action. Both still start from a queue, so skills-based routing narrows who gets the work rather than replacing queues.
A practical rule: begin with queues, and add skills only when you can name the specific misroute they will prevent. If Spanish-speaking customers keep reaching English-only reps, a language skill is justified. If the case is simply that skills sound more advanced, the extra upkeep rarely pays back.
Capacity: the setting that makes or breaks adoption
Each rep has a capacity total, and each work item uses up part of it. A rep with a capacity of 6 might take two chats worth 2 each and a case worth 2, or one call that consumes all 6. Salesforce offers two capacity models, and the difference matters more than most teams expect.
With tab-based capacity, a rep frees capacity by closing the work tab in the service console. With status-based capacity, capacity is released when the work item reaches a status you define, such as closed or waiting on customer, and work stays assigned to reps even while they are away or have closed the tab. Status-based capacity suits cases that take days; tab-based capacity suits short conversations handled start to finish in one sitting. Many orgs run messaging on one model and cases on the other.
Size capacity from real handle times, not from what a manager hopes. Numbers set too high flood reps and teach them to go offline to cope, while numbers set too low leave queues growing while reps have spare time.
Presence statuses and channels
Presence statuses are how reps tell Omni-Channel they are ready. Keep the list short and meaningful: an available status per combination of channels your reps really work, plus a few busy statuses such as break, training or meeting. Grant access by profile or permission set so reps see only the statuses that match their role.
Channels behave differently. Cases can wait hours, so they are forgiving of a rep stepping away. Messaging and chat expect a reply within minutes, which makes push timeout, the window a rep has to accept before the item moves on, worth tuning. Voice is the least forgiving; calls usually go to reps in a status dedicated to phone work, and the telephony setup, whether Service Cloud Voice or a partner platform, adds its own routing considerations to plan together with Omni-Channel.
The supervisor view
Supervisors watch Omni-Channel from Command Center for Service, the tool previously called Omni Supervisor. Its tabs show each rep's status, channels, queues and how close they are to capacity; the queue backlog and skills backlog with wait times; and the work currently assigned. Supervisors can change a rep's status from there and drill into individual reps, queues and work items.
Use it for decisions, not just watching. A queue whose longest wait keeps climbing while reps show spare capacity points to a presence or eligibility problem, not a staffing one. A skills backlog that only grows during certain hours tells you where cross-training would help.
Common mistakes
- Leaving agents free to pick from list views alongside Omni-Channel, so the best work gets cherry-picked and routing data becomes meaningless.
- Giving every queue the same priority, which turns routing into a pure first-in, first-out line.
- Building a queue for every combination of product, region and tier instead of using a few skills.
- Requiring skills that no online rep holds after hours, with no fallback queue or timeout rule.
- Adding presence statuses until reps cannot tell which one actually receives work.
- Choosing tab-based capacity for long-running cases, so capacity frees up while the work is still open.
- Changing routing in production without a sandbox test and a note to supervisors about what changed.
Review routing every quarter with the people who use it. Pull wait times by queue, time to accept by channel and items with no eligible rep, and ask supervisors where they are overriding routing by hand. Each manual override is a rule waiting to be written down.
