Salesforce Omni-Channel Routing: Setup, Skills, and the Summer 26 Retirement

Salesforce Omni-Channel is the work distribution engine that pushes cases, leads, chats, and calls to agents automatically based on availability, capacity, priority, and skills, instead of letting people cherry-pick a queue. The big change in 2026: Salesforce retired Standard Omni-Channel in the Summer '26 release. Orgs were auto-upgraded to Enhanced Omni-Channel, and any org that did not upgrade loses Omni-Channel login, which means no work gets assigned at all. This guide covers the retirement, the routing types, how to set it up, and the gotchas that break real implementations.

Standard Omni-Channel was retired in Summer '26

Start here, because most guides on this topic are still written against the old model. Salesforce ended life for Standard Omni-Channel in the Summer '26 release and automatically migrated orgs to Enhanced Omni-Channel during the rollout. Salesforce's own release note is blunt about the consequence: if your org did not upgrade and was not auto-upgraded, users cannot log in to Omni-Channel, so Omni-Channel assigns them no work.

Rollout landed in sandboxes around May 8, 2026 and in production around June 13, 2026, with automatic migration waves running by region through April and May. If routing quietly stopped working in your org this summer, this is the first thing to check.

Enhanced Omni-Channel has prerequisites worth confirming: your core org needs to be on Hyperforce, the SCRT2 domain (*.salesforce-scrt.com) has to be allowed in your network configuration, and the AWS terms need to be accepted. Orgs still on legacy Chat or Standard Messaging had to move to Enhanced Chat and Enhanced Messaging first, since those reached end of life in February 2026. If you still have to make the switch, our Enhanced Omni-Channel migration guide walks through the prerequisites and cutover step by step.

Salesforce states that everything Standard did is supported in Enhanced. Enhanced adds a Paused status on service channels alongside In-Progress and Complete, the Omni-Channel Supervisor Wallboard, skill proficiency, and multiskill routing. One removal to plan around: the Transfer Skills button on the Omni-Channel widget is gone, so use the standard transfer action or a custom Flow.

What is Salesforce Omni-Channel routing?

Omni-Channel is a work distribution engine inside the Salesforce console. It takes work items, which can be cases, leads, orders, chats, voice calls, messaging sessions, or custom objects, and pushes each one to an agent in real time based on who is available, how much capacity they have left, how the queue is prioritized, and optionally which skills the item requires. The point is to remove the pull model, where agents scan a queue and pick what they want, and replace it with a push model the business controls.

Service channels are what make an object routable. You can turn nearly any Salesforce object into a routable work record, which is why Omni-Channel gets used well beyond support cases.

The routing types: queue-based, skills-based, and flow

Salesforce's help docs split routing three ways (plus external), while its marketing site uses a slightly different three-way split that includes priority-based. The docs version is the one that matches what you actually configure.

Salesforce's own guidance is that smaller companies in limited geographies with fewer products usually prefer queue-based because it is simpler to set up, while larger companies expanding across geographies and product lines prefer skills-based because it routes on a more sophisticated set of criteria.

There are three ways to actually invoke skills-based routing: declarative Skills-Based Routing Rules that map field values to skills (supported on Case, Lead, Order, and custom objects), Omni-Channel Flows that set skill requirements in Flow Builder, or Apex writing directly to PendingServiceRouting and SkillRequirement.

One structural note on flows: for real-time channels like chat and voice the flow launches when the conversation starts, but for non-real-time objects like cases and leads you build the routing logic in an Omni-Channel flow and invoke it as a subflow from a parent record-triggered flow.

How to set up Omni-Channel routing in Salesforce

1. Enable Omni-Channel. Setup, then Feature Settings, Service, Omni-Channel, Omni-Channel Settings, and check Enable Omni-Channel. This is also where you enable Skills-Based Routing and the Status-Based Capacity Model.
2. Create service channels. Define which object becomes a routable work item, and set the capacity model and the in-progress, paused, and complete statuses per channel.
3. Create presence statuses. These are the states agents pick, such as Available, Busy, or On Break. Each is either online and mapped to one or more service channels, or busy/offline.
4. Grant access to presence statuses. Through a profile or permission set, add the status in the Available Service Presences list. Agents who are online with a status not mapped to the right channel receive nothing.
5. Create routing configurations. Set routing priority, routing model, push time-out, and how much capacity each work item consumes.
6. Create queues with the object and members, then attach the routing configuration.
7. For skills-based routing, create Service Resources and Skills. Register users as agents, attach skills to the Service Resource, and build Skill Mapping Sets under Setup, Omni-Channel, Skills.
8. Create presence configurations. Assign users, set overall capacity, and choose console behaviors like auto-accept and decline reasons.
9. Add the Omni-Channel utility. Setup, Apps, App Manager, edit your Service Console app, and add Omni-Channel to Utility Items. Salesforce recommends the sidebar layout over the utility bar footer.

How does capacity work in Omni-Channel?

Capacity is split across two objects, and this is the part teams most often get wrong. The presence configuration sets the agent's overall capacity, the total amount of work they can hold at once. The routing configuration sets how much of that capacity each individual work item consumes, either in units or as a percentage. So if a case consumes 2 units and an agent has a total capacity of 10, that agent can hold exactly 5 of those cases at once.

Because Omni-Channel counts abstract work units rather than conversations, a chat and a case can legitimately cost different amounts, which is the whole point of the model.

You also choose a capacity model per service channel. Status-based capacity determines capacity from the status of accepted work, so work stays assigned and counted until it is completed or reassigned even if the agent closes the tab, and it supports pausing. Tab-based capacity releases capacity when the work tab closes in the console. Only status-based capacity works in standard, non-console apps, which is a quiet source of breakage.

Routing model: Least Active versus Most Available

The routing model on your routing configuration decides how work spreads across eligible agents. Least Active routes to the agent with the fewest open work items. Most Available routes to the agent with the largest gap between their capacity and their open work. When agents tie, Omni-Channel prioritizes reps with no active work items and picks whoever logged in earliest.

Worth naming plainly: there is no native round-robin in Omni-Channel, no territory-based model, and no native way to cap how many records someone gets per hour or per day. Omni-Channel distributes by workload, not by turn. If you need true rotation or per-period caps, that is Flow or custom code territory.

Gotchas that break real Omni-Channel implementations

Skills live on the Service Resource, not the User. This trips up nearly everyone, because it feels like it belongs on the user record. Every rep needs skills attached through the Service Resource object.

Skills-based routing is a chain, not a toggle. Enable it, create skills, create service resources, attach skills, build mapping sets or a flow, and enable the routing configuration for skills-based rules. Miss one link and nothing routes.

Routing logic is not reapplied. Routing runs when work is assigned an owner. If you change field values on the work item afterward, the logic does not run again, so re-prioritizing a case post-routing does nothing on its own.

Declines still count as assignment. Omni-Channel treats work as assigned when it routes it, whether or not the rep accepts. Naive "assignments per agent" reporting will be distorted by this.

Going offline recalculates capacity. When a rep goes offline and returns, it counts as a new session and capacity is recalculated, which explains a lot of "where did their work go" tickets.

Transfers create a new AgentWork record. Each work assignment is an AgentWork record, and transferring work between agents creates another one. If you do not account for that, you will double-count handle time in reports. The useful fields for reporting are SpeedToAnswer, HandleTime, CapacityWeight, RoutingType, and RoutingModel.

Capacity is the most under-configured piece of most builds. Teams get skills right, leave every rep on the default capacity weight, and then wonder why one senior agent is buried while three colleagues sit idle.

What Omni-Channel does not route

Service channels cover cases, leads, orders, chats, messaging sessions, and custom objects. Accounts, contacts, opportunities, and tasks are not part of that set, which surprises sales-side teams who assume Omni-Channel can distribute opportunities the way it distributes cases. If you need to assign those, you are looking at assignment rules, Flow, or a tool that sits outside Omni-Channel.

Frequently asked questions

Is Salesforce Omni-Channel free?

It is not a separate purchase, but it is licensed rather than universally available. Salesforce documents Omni-Channel as available with the Agentforce Service (formerly Service Cloud) license or add-ons including Digital Engagement, Enhanced Chat, Salesforce Voice, and Workforce Management. Check your license and add-ons rather than your edition alone, since what you get depends on which add-ons are bundled.

What is the difference between queue-based and skills-based routing?

Queue-based routing sends work to any available member of a queue, so the queue itself represents the capability. Skills-based routing sends work to a rep who holds all the required skills and has spare capacity, so one queue can serve many skill combinations. Queue-based is simpler to run; skills-based scales better across products and regions.

Does Salesforce Omni-Channel support round robin?

Not natively. Omni-Channel distributes by workload using Least Active or Most Available, both of which look at current open work rather than whose turn it is. True round-robin rotation requires an Omni-Channel Flow, custom Apex, or a dedicated assignment tool alongside Salesforce.

Why is Omni-Channel not assigning work to my agents?

Work the usual suspects in order: confirm the org is on Enhanced Omni-Channel after the Summer '26 retirement, check the agent's presence status is online and mapped to the right service channel, confirm the status is granted via profile or permission set, and check whether the agent is already at capacity. Stuck capacity is common enough that Salesforce publishes a dedicated article on clearing it. Our step-by-step guide to Salesforce Omni-Channel not assigning work walks through each cause and fix in the order worth checking.

Where a routing layer fits alongside Omni-Channel

Omni-Channel is genuinely strong at what it was built for: pushing service work to console agents by capacity and skill inside Salesforce. Its limits are also clear. There is no native rotation, no per-period caps, it only routes the objects service channels support, and configuration complexity is real enough that most orgs run it well below its capability.

Assigner is a lighter option for teams that want fair, explainable assignment without a full Omni-Channel build, or that need to route work Omni-Channel does not cover. It sits beside Salesforce and assigns each item by skill, current workload, and availability using rules you control, including true round-robin and weighted rotation, then shows exactly why each person was chosen. The same engine also routes support tickets and ops tasks. If you are budgeting a Salesforce service build, it is worth watching what the per-conversation AI charges add up to alongside your other software and cloud spend before committing.

For the Salesforce-specific rotation problem, see round robin assignment for Salesforce leads, compare the native options for support work in our guide to Salesforce case routing, or read how to structure the logic itself in writing lead routing rules. Assigner is a companion designed to help, not a live two-way sync, and nothing about the outcome is guaranteed.