What it does

Unified routing applied to Dataverse records rather than conversations. You enable a record type for routing, build a record workstream, and the routing engine classifies each record, picks a queue, then assigns it to a named person based on their presence, capacity and skills.

Key facts

• Turned on in the Copilot Service admin center under Routing > Manage unified routing > toggle Unified routing to Yes. It is off by default in a Customer Service-only environment.
• Record types have to be added individually under Routing > Record routing > Manage before a workstream can use them. Cases are the usual first one; any routable table works, including email and other activities.
• The workstream Type is set to Record and cannot be changed afterwards. Same for Work distribution mode (Push or Pick) in practice — treat it as a build-time decision.
• Intake rules sit above the workstream and decide which workstream (or the legacy basic routing ruleset) a given record goes to. The quota is 100 intake rules per organisation.
• Records that arrive without a matching intake rule are not routed. Active basic routing rulesets also stop firing for a routed record type until intake rules exist, which is the classic "nothing routes any more" symptom after go-live.
• Every user who can receive routed work must exist as a bookable resource and be a member of at least one private queue. Public queues and empty queues get no automatic assignment.
• Assignment for record work items runs on an event-driven cycle plus a periodic sweep roughly every five minutes, so records do not land instantly the way a chat does.
• Configuration changes propagate to the routing service within about 15 minutes. Don't judge a config change in the first ten.
• Routing writes to msdyn_ocliveworkitem and queueitem; assignment sets the record owner, the live work item agent and the queue item Worked By. PickFromQueue is not supported against unified routing work items.

When to use / skip

Use it whenever case assignment needs to be more than "drop it in a team queue and hope". If the client wants cases pushed to a named person, balanced by workload, or matched to a language or product skill, unified routing is the only supported way to do it and basic routing rulesets will not get you there.

Skip it if the operating model is genuinely pull-based and simple — one or two queues, agents picking work off a view, no capacity concept. Turning unified routing on for that adds a routing service, bookable resources, capacity profiles and a whole second layer of debugging for no operational gain. Also skip it on Professional: unified routing sits in the Enterprise and Premium SKUs, so confirm the licence position against the current Dynamics 365 licensing guide before you design around it.

Configuration decisions

• Which record types go through unified routing at all, and which stay on basic routing rulesets or manual queue assignment. Mixing both in one org is normal; mixing both on one table is not.
• Push versus Pick distribution. Push assigns an owner automatically; Pick leaves records in the queue for agents to take from the inbox. Push is the point of the feature, but Pick is defensible where the client wants agents to self-select.
• Whether one workstream handles all cases with classification rules doing the work, or several workstreams split by intake rule (region, language, business unit). Fewer workstreams is easier to reason about.
• Unit-based or profile-based capacity for the workstream, and whether case work should consume capacity at all alongside conversation work.
• The fallback queue for the workstream, and whether it is a real supervised queue or a black hole nobody watches.
• Whether agents work routed cases in Copilot Service workspace. Notifications for routed records only surface there — not in Customer Service Hub, and not in Unified Service Desk.

Gotchas

• Capacity for a routed case is only released when the case is resolved or cancelled, or the Worked By value is cleared. For non-case records and activities nothing releases capacity automatically — you have to deactivate or delete the queue item, usually with a bit of custom logic. Teams that skip this find every agent permanently at full capacity a fortnight after go-live.
• Custom plugins and flows that fire on the case owner or queue item during the assignment window will fight the routing service. Keep automation off msdyn_ocliveworkitem entirely and update queue items one field at a time.
• Advanced queues can't be associated with a mailbox. If the client relies on queue-based email intake, you still need basic queues alongside, and moving records between the two needs Save & Route rather than a straight queue change.
• Intake rules and route-to-queue rules both support only two levels of related records. Anything deeper needs a rollup or calculated field on the record itself, decided early.
• Turning unified routing on is easy; turning it off cleanly is not documented, and the record types you enabled stay enabled. Treat enablement in production as effectively one-way and prove the design in a sandbox first.
• The "keep the same agent" affinity toggle isn't available for case workstreams — cases stay with the first assignee by design, which surprises clients expecting reassignment on reopen.

Consultant notes

• Demo the diagnostic path, not just the happy path. Clients accept routing far more readily once they've seen how you show them why a specific case went to a specific person.
• Insist on a named owner for fallback queues before go-live. Every unified routing implementation I've seen has a fallback queue, and about half of them have nobody looking at it.
• Push back on capacity numbers pulled out of the air. Get the client to state how many open cases a person should hold, then set the profile to that, and expect to revise it in month two.
• Check bookable resource creation as part of the joiner process, not as a one-off migration task. New starters who aren't bookable resources simply never receive work, silently.
• Budget real time for user provisioning: bulk changes above roughly 500 requests per 15 minutes start producing inconsistent skill and capacity data.

---

Worth another look if the client moves email intake onto advanced queues, or when record assignment timing changes in a future wave.