Dynamics 365 Contact Center: Preferred and Previous Expert Routing Setup, Rules and October 2026 GA

Microsoft is addressing this friction directly in Dynamics 365 Contact Center through an update to unified routing tracked under AI at Work roadmap ID 576746 ("Dynamics 365 Contact Center: Unified routing - Assign conversation to expert who engaged with the customer previously"). Rather than relying on rigid, fragile routing rules, the capability uses natural-language playbooks inside Conversation Orchestration to reconnect returning customers with either a designated preferred representative or an expert who previously handled their issue—complete with bounded lookback windows, presence verification, active capacity checks for asynchronous messaging, and automated fallback to the broader queue when that familiar face is unavailable.

Here is a deep dive into how the routing hierarchy actually works under the hood, the shifting rollout timeline across Microsoft's administrative portals, and the operational guardrails IT and contact center leads need to know before publishing these playbooks into production.

Rollout Timeline and Roadmap Context​

If you have been tracking this feature across Microsoft's various administrative feeds, you may have noticed the dates shifting over the past few months.

According to Microsoft's AI at Work roadmap (ID 576746) and the archived Dynamics 365 2026 release wave 1 plan on Microsoft Learn, the feature entered public preview in June 2026 (specifically June 30, 2026, per the release plan and M365 Admin reporting) and is slated for General Availability in October 2026 for Worldwide (Standard Multi-Tenant) web environments.

However, archival records from the Microsoft 365 Message Center show a slightly more nuanced path to general availability:

• Under Message Center post MC1446228 in early August 2026, Microsoft initially targeted general availability for August 28, 2026, before updating the advisory on August 17 to note that the release had been postponed.
• A subsequent Message Center notice, MC1483413, published on September 30, 2026, set the revised General Availability target for October 30, 2026.

Meanwhile, Microsoft's underlying technical documentation on Microsoft Learn still labels Conversation Orchestration and the preferred/previous expert playbook capability as a "production-ready preview" subject to supplemental terms. Because roadmap and Message Center dates represent projected rollout targets rather than guaranteed activation in every individual tenant, administrators should check their Copilot Service admin center directly as the October window closes.

(Note: As Microsoft noted on its release plan pages, as of fall 2026 the company has archived its standalone Dynamics 365 release plan pages and consolidated ongoing tracking for Dynamics 365, Power Platform, and Dataverse into the unified AI at Work roadmap.)

How the Decision Hierarchy Works​

At the heart of this update is a structured decision hierarchy that triggers when a conversation is routed to a queue (Conversation routed to queue). Instead of treating "preferred agent" and "last agent spoken to" as separate, isolated features, Conversation Orchestration evaluates them in a configurable sequence.

According to Microsoft Learn's administration documentation for Dynamics 365 Contact Center, the system evaluates three tiers by default, though administrators can flip the precedence between the first two to match their business model:

The Three Gatekeepers: Recency, Queue Membership, and Presence​

Crucially, the system does not blindly dump a returning customer onto an agent's desk just because they spoke last Tuesday. Before assigning the conversation to a previous or preferred expert, unified routing validates three strict criteria:

1. Recency Window (for Previous Experts): Administrators define how far back the system should inspect interaction history—such as 7, 10, or 30 days—with the platform supporting a cutoff period of up to 30 days. Using context variables (like CustomerTier or Is VIP Customer), you can tailor this window by segment. For example, Microsoft's sample architecture applies a 20-day lookback for VIP Tier 2 customers, 10 days for VIP Tier 1, and 7 days for general inquiries.
2. Queue Membership: The target expert must be an active member of the specific queue to which the incoming conversation was routed. If an agent helped a customer in a Billing queue last week, and the customer contacts Technical Support today, the Billing agent will not be pulled out of their lane unless they also belong to the Technical Support queue.
3. Presence Check: The expert must currently be signed in with an allowed presence status. If the previous expert is offline or unavailable, the check fails immediately at T=2 in the evaluation timeline, triggering the queue's standard fallback assignment so the customer isn't left waiting.

Summary: Synchronous Routing Logic​

• Trigger: Conversation enters a queue.
• Lookback Cap: Up to 30 days for previously engaged experts.
• Safety Valve: Immediate fallback to the queue's standard assignment method if the target expert is offline or not in the target queue.

Asynchronous Messaging: Representative Affinity and Active Conversation Limits​

Live voice calls and synchronous web chats are relatively straightforward: either the agent is available right now, or they aren't. Asynchronous messaging channels (such as persistent chat or social messaging where a customer replies hours later after a conversation has moved to a "waiting" state) are much trickier.

To prevent returning asynchronous threads from burying a single popular representative while still preserving context, Microsoft pairs representative affinity with a dedicated playbook template: Keep the same expert for async chats.

When a customer reinitiates a waiting asynchronous conversation on a workstream where representative affinity is enabled, the system runs a two-part check on the previously engaged expert:

1. Allowed Presence Status: The representative must be in one of the presence states explicitly permitted by the playbook.
2. Active Conversation Limit: This is a representative-level attribute that caps how many capacity-occupying conversations an agent can hold across all channels when returning async chats are evaluated.

Active Conversation Limits vs. Capacity Profiles​

From an architectural standpoint, one of the most important details in Microsoft's documentation is how the active conversation limit interacts with standard capacity profiles:

• New Conversations: Governed strictly by capacity profiles, not the active conversation limit.
• Waiting Conversations: Consume zero capacity while sitting in a waiting, unassigned state. They only count toward the limit when the customer actually replies and reinitiates the thread.
• Reconnecting Async Chats: When the customer replies, the system compares the representative's total active, capacity-occupying conversations across all channels against their active conversation limit. If their current load is below that limit, the system reconnects the chat to that same representative—even if the active conversation limit is set higher than their standard capacity profile.
• Fallback Options: If the representative is over their active conversation limit or in a disallowed presence state, the playbook follows the administrator's chosen fallback: either assign to the next best expert in the queue or keep the chat unassigned in the queue. (Microsoft notes one edge-case exception: if no other suitable representative is available, the conversation might still return to the original representative.)

How to Configure Playbooks in Copilot Service Admin Center​

Conversation Orchestration is available for voice and messaging channels and requires Unified Routing to be enabled, along with System Administrator or Omnichannel Administrator privileges. (If your organization runs on the Power Platform Pay-as-you-go plan, an Azure subscription with consumption-based billing is also required.)

1. Prerequisites for Preferred Expert Routing​

If your playbook includes Preferred Expert logic, you must first map contacts to their representatives in the Copilot Service admin center:

• Navigate to Routing and select Manage next to Preferred representative routing.
• Enable the feature, choose a default fallback behavior, and use the Preferred representatives matrix to map contacts to up to three ordered representatives.
• Ensure incoming channels can identify the customer record (for example, authenticated chat, pre-conversation survey Name mapping, or phone-number authentication for voice).
• Note for custom security roles: Administrators or custom roles managing traditional preferred representative tables must have access to the Contact, msdyn_preferredagent, and msdyn_preferredagentcustomeridentity tables.

2. Building the Conversation Orchestration Playbook​

To configure the dynamic lookback or async affinity rules:

1. Open the Copilot Service admin center and navigate to Customer support > Conversation Orchestration (Preview).
2. Select Prompt gallery.
3. In the scenario category dropdown, select Assign to a previous or preferred expert (which appears under the Assign to a predicted expert category in the orchestration gallery).
4. Choose either the standard returning-customer assignment template or the Keep the same expert for async chats template.
5. Under Queues > Edit, select your target channel (Voice or Messaging) and choose whether the playbook applies to All queues, a List of specific queues, or All queues except selected exclusions.
6. (Optional) Add Context Variables: Select Add customer attribute to bring in variables such as CustomerTier, Is VIP Customer, Preferred Language, Customer Region, or Account Type. A single playbook supports up to 10 conditions, and each condition can evaluate up to two context variables.
7. Define your natural-language rules (such as lookback days per customer segment or allowed presence states and active conversation limits for async chats).
8. Click Save to store the playbook as a Draft, review any system validation warnings, and click Publish to make it live.

Critical Operational Caveats for IT Admins​

Before rolling this out across enterprise support queues, veteran administrators should pay close attention to four operational realities buried in the technical documentation:

• Language Model Compilation Needs Runtime Testing: When you write or customize a natural-language playbook and hit Publish, Dynamics 365 uses a language model to translate your prose into a structured runtime format. Microsoft explicitly warns that this conversion might not fully capture the intended playbook logic, and deviations can only be spotted during runtime. Never publish a complex multi-tier prompt on Friday afternoon without running test conversations through your queues first, and use custom diagnostic queries to verify how orchestration is evaluating each call or chat.
• Cross-Playbook Conflicts Only Trigger at Publish: You can run multiple playbooks on the same queue if they cover different scenarios (for example, one playbook for Wait-Time Dynamic Prioritization and another for Agent Availability Overflow). However, you cannot have two active playbooks for the same scenario and the same queue. The system does not check for these conflicts when you save a Draft—it only runs cross-playbook validation when you click Publish.
• Deleting an Active Playbook Cuts Off Orchestration Immediately: Active playbooks have their standard "Save" button disabled (forcing you to use Save & publish or cancel back to the last live version). If you delete an active playbook from the Playbook tab, conversation orchestration stops for that queue immediately.
• ALM Solution Imports Require Pre-Existing Dependencies: You can migrate playbooks from Sandbox to Production using standard Power Platform Solutions. However, because a playbook references environment-specific records like queues and context variables, every referenced table, queue, and variable must already exist with matching names and configurations in the destination environment before you import the solution, or the import will fail.
• Compliance and Employee Governance: Microsoft includes a prominent governance notice stating that this routing and analytics functionality is designed to help supervisors improve team performance and customer satisfaction—not to make employment decisions regarding compensation, rewards, seniority, or entitlements. Organizations remain responsible for complying with local monitoring, recording, and consent laws for both end users and service representatives.

The Bottom Line for Enterprise Support Teams​

Used thoughtfully, unified routing's ability to reconnect customers with a previously engaged or preferred expert solves one of the oldest frustrations in customer service without trapping callers in single-agent dead ends. By combining a hard 30-day maximum lookback window, strict queue and presence checks, and a separate active conversation limit for returning asynchronous chats, Dynamics 365 Contact Center gives administrators fine-grained control over continuity versus speed.

If you manage a Dynamics 365 Contact Center environment on the Windows Forum community, how are you planning to balance your lookback windows—giving VIPs a longer 20-to-30-day memory while keeping general queues on a tight 7-day leash, or prioritizing preferred relationship managers first? Share your routing strategies and testing experiences in the discussion thread below.