Unified routing or basic queue-and-assign

What it does

Customer Service has two routing engines. Basic routing rulesets evaluate conditions on a case top to bottom and drop it in a queue; a human then picks it up. Unified routing classifies the work item, then assigns it to a named person based on skills, capacity and presence, across cases and conversations alike. They solve the same problem at very different levels of ambition and cost to run.

Key facts

Basic routing rulesets apply to cases only. Unified routing handles any record type, including activities such as email, plus every conversation channel.
With unified routing not enabled, only one basic routing ruleset can be active at a time, and you must deactivate it to edit it.
Basic rule criteria carry real limits: no time values on date/time fields, only one level of related-entity hierarchy, no multi-select option sets, lookups restricted to equal, not equal, null and not null, and you cannot use the same related entity more than once in the conditions.
Basic routing is pull. The case lands in a queue and waits. Unified routing is push — it offers the item to a specific person and, if they do not take it, re-offers it, with the assignment offer limit configurable.
Unified routing runs in two stages. Classification adds context (skills, priority, category, sometimes via a machine-learning model); assignment then matches that context against agent skills, capacity profiles and current workload across channels.
Enabling unified routing automatically migrates existing queues into it. That is convenient and it is also the point of no easy return.
Unified routing is configured in the Copilot Service admin center and agents must work in Copilot Service workspace to receive assigned work. It is not supported in Unified Service Desk.
Unified routing carries its own licensing requirement on top of the base seat. Confirm it against the current licensing guide rather than assuming Enterprise covers everything.

When to use / skip

The instinct on every project is to reach for unified routing because it is the newer, better engine and Microsoft's own documentation recommends it. Resist that for a moment and look at the operating model, because unified routing is only better if the organisation is actually going to run it.

Unified routing pays for itself when there is real specialisation and real volume. Multiple skills, multiple languages, agents who work chat and cases at the same time, and a supervisor who cares about even distribution — that is the profile. Push assignment removes queue-cherry-picking, capacity profiles let one agent hold three chats and one case sensibly, and skills-based matching stops the tier-two specialist getting password resets. None of that is achievable with rulesets.

Basic routing is enough, genuinely enough, when a team of fifteen people work a shared inbox by category, everyone can handle everything, and the supervisor reassigns by hand twice a day. Setting up workstreams, capacity profiles, skill taxonomies and assignment methods for that team is a month of configuration producing an outcome the shared queue already delivered. Most projects that fail with unified routing fail because they configured a model nobody had the appetite to maintain.

So: default to unified routing for anything with conversations in scope, because there is no alternative there — conversations do not route through rulesets at all. For case-only implementations, default to basic routing unless you can name the skills, name who owns them, and show more than one team that needs different work. If you cannot, start basic and move later. Moving up is a project; moving down is worse.

The contrarian case: I would take unified routing early even for a modest case-only team when the client has a firm roadmap to add chat within a year. Building the queue structure twice is the more expensive mistake.

Configuration decisions

Whether to enable unified routing on the environment at all. Because it migrates existing queues on activation, treat this as a one-way door and make it deliberately.
The skill taxonomy: how many skills, who defines the proficiency scale, and whether skills are maintained by supervisors or by an HR-driven process. Skills nobody updates are worse than no skills.
Capacity model: unit-based capacity or capacity profiles. Profiles are the right answer for mixed channel working, and the wrong answer if the client only ever does cases.
Assignment method per queue — highest capacity, round robin, or a custom assignment method. Custom methods are powerful and are the thing that turns into unmaintainable code if you are not careful.
Whether overflow, operating hours and fallback queues are configured in phase one. They are usually the reason go-live weekend goes badly when they are not.

Gotchas

Turning unified routing on migrates queues automatically and there is no documented clean route back. Do it in a sandbox first, and do not do it on a Friday.
Push assignment changes agent behaviour hard. Agents who chose their own work now get told what to work on, and if you have not sold that change to the floor before go-live it comes back as "the system is broken".
Agents must be in Copilot Service workspace and must set presence for assignment to work. Half the day-one incidents on a routing go-live are agents left on Offline.
Unified routing licensing is separate from the general Enterprise entitlement. Configuring it in an environment where it is not licensed works technically and fails at audit.
Capacity profiles set too generously make the engine look broken because everything is assigned instantly to whoever is nearest; set too tightly and work sits unassigned while agents idle. Expect to tune this for weeks after go-live.

Consultant notes

Ask the supervisor, not the sponsor, how work is allocated today. If the answer is "people pick their own", unified routing is a change programme with a configuration exercise attached, and price it that way.
Demo the agent side of push assignment early. The notification, the timer and the re-offer are the parts that provoke reaction, and you want that reaction in design, not UAT.
Before go-live, run a day of simulated volume with real agents and watch the unassigned queue. That single exercise catches more configuration problems than any amount of desk checking.

Worth another look if Microsoft ever documents a supported way back from unified routing, or when the licensing guide restates what the routing entitlement covers.