Advanced queues and overflow handling

What it does

Advanced queues are the queue type unified routing assigns from. Each one is bound to a channel type, has its own priority, member list and assignment method, and carries the overflow rules that decide what happens when work piles up faster than the team can clear it.

Key facts

Two flavours coexist: basic queues (the classic Customer Service queue, still used for mailbox-backed email intake) and advanced queues (created for unified routing). They are not interchangeable.
Advanced queues are typed as Records, Messaging or Voice. The type is fixed at creation and stops a case ever landing in a chat queue. In a Customer Service-only build you mostly care about Records.
Queue priority is a number where lower wins. Priority 1 is served before priority 2. Queues of equal priority fall back to FIFO across the set; with custom prioritisation rules they're ordered alphabetically, which is rarely what anyone intends.
Three system queues ship out of the box — Default entity queue, Default messaging queue, Default voice queue. All Omnichannel users are members and only the assignment method is editable.
A default queue can be used as a fallback queue for a workstream. The reverse doesn't work: you can't promote an ordinary queue into a default queue.
Automatic assignment only happens from private queues with at least one member. A public queue is a holding area, not a routing target.
Advanced queues cannot be associated with a mailbox. Mailbox-driven intake stays on basic queues.
Overflow handling is configured per queue under Overflow handling, with separate condition sets for before the item is queued and after it's been sitting there.
For Records, the pre-queue condition available is out of operating hours, with actions to assign anyway or transfer to a different queue. Post-queue, the condition is waiting time in queue (3 minutes to 2 days for records), with transfer to a different queue as the action.
Work item limit conditions run on a 10-second check and accept 1 to 100 items. Where more than about 20 items overflow in a minute the service batches them, favouring queues with lower wait times.
Route-to-queue rules can override queue-level overflow with Handle rule-specific overflows, so one rule's traffic can behave differently from the queue default.

When to use / skip

You don't get a choice about advanced queues — if you're using unified routing, you're using them. The real decision is how many, and that's where projects go wrong in both directions. A queue per team plus a fallback is usually right. A queue per product line per region per language is a maintenance liability that will be flattened within a year.

Overflow handling is more optional than people think. For a records-only Customer Service build the available levers are thin: out-of-hours and queue wait time, with transfer as the main action. If the client's escalation model is "a supervisor watches the dashboard and moves things", say so plainly rather than building overflow rules that duplicate a human process less well.

Where overflow genuinely earns its place is out-of-hours coverage across time zones — routing overnight cases to a queue in another region automatically, rather than having them sit until morning. That one is worth the configuration.

Configuration decisions

Queue granularity: split by skill and let skill matching narrow within a queue, or split by queue and keep matching simple. Pick one philosophy and hold it.
Priority numbering scheme, with gaps. Use 10, 20, 30 rather than 1, 2, 3 so you can insert a queue later without renumbering everything.
Assignment method per queue — highest capacity, advanced round robin, least active, or a custom ruleset. This is set on the queue, not the workstream, so it varies queue by queue.
Fallback queue per workstream, and whether it's the default entity queue or a purpose-built supervised one.
Whether overflow conditions live at queue level or on specific route-to-queue rules, and what the transfer target chain looks like so you don't create a loop.
Queue membership model: direct users, or teams. Team-based membership scales better but makes "why did this person get it" harder to explain.

Gotchas

Queue type is set at creation and can't be changed. A Records queue built by mistake as Messaging has to be rebuilt, which means re-pointing every rule that referenced it.
Emptying a queue's membership doesn't disable it. Work still routes there and then sits unassigned forever, because there is nobody to assign to. Nothing errors.
Setting queue ownership on routing is controlled by msdyn_issetowneridfromqueueoninitenabled on the Omnichannel configuration. If the client expects the case business unit to follow the queue, this has to be switched on deliberately.
Overflow transfer targets can chain into each other. Queue A overflows to B, B overflows back to A, and items ping-pong. Nothing in the UI warns you.
Metrics thresholds on the queue (Service Level Threshold, Short Abandoned Threshold) look like SLA settings but only feed routing metrics and dashboards. They are not entitlement SLAs and don't drive any SLA action.
Queue configuration changes take up to 15 minutes to reach the routing service. Testing a priority change immediately after saving will mislead you.

Consultant notes

Draw the queue map on one page before building anything: queue name, type, priority, members, assignment method, fallback. If it doesn't fit on a page, the design is too complex for the client to run.
Demo overflow with the clock, not with theory. Set a two-hour wait threshold in a sandbox, show the transfer, then set the real value.
Tell the client that queue priority is not case priority. They will conflate the two in the first workshop, every time.
Before go-live, walk every queue and confirm it has at least one active, licensed, bookable-resource member. This single check catches more day-one incidents than any other.
Keep basic queues alive if email intake matters, and document which queues are which. A support team that can't tell an advanced queue from a basic one will file bugs against both.

Worth another look if overflow gains richer record-channel conditions, or if the client adds a second support region.