What it does

The settings that decide how representatives hand live conversations on: consult another representative or a queue, transfer to a queue or a named person, and, new in 2026, reroute, which hands the conversation back to unified routing to be routed again from scratch using whatever the representative has just updated.

Key facts

• Out of the box representatives can consult other representatives and transfer to queues. Consult to queue and direct transfer to representatives need switching on.
• Reroute lives in the Copilot Service admin center under Channels > Consult and transfer > Transfer settings and is off by default. It was preview from mid-2026. Microsoft's docs commit of 26 October 2026 is titled as GA content for rerouted conversations, while the live Learn page still showed the preview label at the time of writing.
• On reroute the system reruns classification and route-to-queue rules with the updated context, then assigns the conversation to an available representative in the resulting queue. The customer stays connected throughout, and the outgoing representative's capacity is released.
• The capacity profile is swapped for one based on the routing rules. The October 2026 update adds Remove skills on reroute, which replaces the work item's attached skills with new ones based on the requirement rather than carrying the old ones over.
• If no queue matches, the conversation goes to the configured fallback queue.
• Wrap up after transfer only works if Block capacity for wrap up is set in the workstream's work distribution settings.
• Consult and transfer FetchXML filters (four of them, for consult and transfer to queues and to representatives) are all off by default.

When to use / skip

Turn reroute on where misrouted work is common and the fix is a field change: wrong category, wrong priority, wrong account. It saves representatives guessing which queue to pick. Skip it if your route-to-queue rules don't read anything a representative can change, because reroute will just send the conversation back where it came from.

Configuration decisions

• Whether to enable reroute at all, and whether Remove skills on reroute is on. If skills were attached by the first classification, they're usually wrong for the second.
• Which fields representatives are expected to update before rerouting, and whether your routing rules actually evaluate them. That includes fields on the linked case, contact or account.
• Where the fallback queue goes and who watches it.
• FetchXML filters for any deployment with more than one team, so representatives only see the queues and people they should.

Gotchas

• Reroute without a context change is a loop. The conversation comes straight back to the same queue, and representatives decide the feature is broken.
• Rules that evaluate related records (case priority, account tier) need those records updated, not just the conversation. Train for this specifically.
• Keeping old skills on a rerouted item can block assignment in the new queue. That's what the remove-skills option is for.
• Without filters, every representative sees every queue across business units in the transfer panel. It's an operational and compliance problem on multi-team tenants.
• The wrap-up toggle on its own does nothing without the workstream setting.

Consultant notes

• Design reroute alongside the classification rules, not after. If the rules can't be changed by anything a representative touches, reroute adds nothing.
• Make "update the case, then reroute" part of the representative playbook, with the two or three fields that matter written down.
• Watch fallback queue volume in the first weeks after enabling it. A full fallback queue tells you the routing rules have gaps.
• Treat GA status carefully until Learn drops the preview label. Clients on strict no-preview policies will ask.

---

Worth revisiting once Learn publishes the GA wording and the remove-skills option