FetchXML Driven Consults and Transfers in Dynamics 365 Contact Center

Microsoft has begun rolling out a focused but powerful enhancement to Dynamics 365 Contact Center: administrators can now customize consults and transfers so that the set of queues and customer service representatives available during a consult or transfer is dynamically controlled by FetchXML queries configured in the Copilot Service admin center. The change — announced in Microsoft’s Message Center and scheduled for general availability on January 26, 2026 — formalizes administrator control over who shows up as a consult/transfer target and when, enabling targeted handoffs, compliance-aware routing, and smarter consult workflows without code-heavy changes to the routing stack.

Background / Overview​

Dynamics 365 Contact Center ships as Microsoft’s modern, Copilot-enhanced contact center offering. It provides voice and digital channels, integrations with Microsoft Teams telephony, AI-assisted agents, and unified routing logic. Consults and transfers are core voice-channel behaviors: when an agent needs help from a colleague (consult) or needs to hand the caller off (transfer), the system has historically offered standard lists of queues and representatives based on queue membership, presence, or static configuration.
The new capability gives administrators the ability to control those consult/transfer candidate lists using FetchXML — the platform query language already used inside Dataverse — from a dedicated configuration surface in the Copilot Service admin center. Administrators can define FetchXML queries for four scenarios:

• Consult to queue
• Consult with a representative
• Transfer to a queue
• Transfer to a representative

The system will dynamically tailor the options shown to agents during consult/transfer operations according to those queries, letting organizations enforce business rules, target subject matter experts, and reduce misroutes.
Microsoft’s official rollout communications (Message Center note MC1221931) mark this feature as generally available on January 26, 2026, and the Dynamics 365 release planning pages and product documentation reflect complementary changes to consult and transfer behaviors that align with this capability. Additionally, existing voice-channel documentation explains the consult and transfer mechanics (how consult puts a caller on hold, how consults can be public or private, and how consults interact with Teams users and external PSTN participants), which remains relevant for admins implementing these customizations.

---

What exactly changed: a practical explanation​

At a practical level, the change introduces a configuration layer that plugs into the consult/transfer UI flow used by agents. Instead of the system showing a fixed list of candidate queues or reps based purely on membership and presence, Dynamics 365 Contact Center now allows administrators to:

• Build and apply FetchXML query filters for each consult/transfer scenario.
• Use those queries to return a tailored subset of queues or representatives that match business constraints (for example, only reps with a given skill, or queues associated with a product line).
• Control consult behavior from the Copilot Service admin center so that changes are centrally managed by service or platform teams.

Why FetchXML? Because Dynamics 365 and Dataverse already expose organizational data (user records, queue membership, skills, attributes, custom fields) via Dataverse entities; FetchXML is the native declarative query language for that model. Using FetchXML gives admins the flexibility to target combinations of attributes — including custom fields added by partners — without requiring code changes to the routing engine.
Key differences you’ll see in the agent experience:

• When an agent selects Consult or Transfer, the candidate list is now filtered by the administrator-defined FetchXML query for that particular scenario.
• Queries can be configured differently for consults vs transfers (for example, consults might show a broader set of subject matter experts while transfers might be limited to a tiered support queue).
• The consult/transfer flow (placing caller on hold, consult role vs transfer completion, whether transfers use bridged or new-call semantics) continues to follow the existing voice-channel settings.

---

Why this matters: benefits for contact centers​

This is not a cosmetic tweak. Several operational and technical gains follow from putting consult/transfer candidate selection under admin control.

• More accurate handoffs and fewer escalations. By showing agents only the most appropriate queues or specialists, you reduce failed transfers and shorten resolution time.
• Skills and compliance-aware routing. FetchXML can target reps based on skills, certifications, or compliance flags, helping meet regulatory requirements (for instance, limiting transfers of certain case types to certified staff).
• Simpler, declarative admin control. Administrators can iterate on selection rules via FetchXML rather than waiting for engineering work or complex routing customizations.
• Consistency across teams. Centralized configuration in the Copilot Service admin center reduces ad hoc agent workflows and makes consult behavior auditable.
• Integration-friendly. Because FetchXML targets Dataverse entities, organizations can use custom attributes maintained by workforce management or back-office systems to influence consult/transfer behavior without additional middleware.

These improvements translate directly into better customer experience: shorter hold times, more expert-first transfers, and fewer transfers that land with the wrong team or person.

---

How administrators will configure consults and transfers​

The rollout exposes configuration options on a dedicated page — the Consult and transfer page in the Copilot Service admin center — where administrators will define FetchXML queries for each scenario. The configuration flow is intentionally declarative; here’s a high-level walkthrough of the typical steps administrators will perform:

• Sign into the Copilot Service admin center with an account that has Dynamics 365/tenant admin privileges.
• Navigate to the Consult and transfer configuration page.
• For each scenario (consult to queue, consult with representative, transfer to queue, transfer to representative), create or paste a FetchXML query that returns the desired set of queues or user records.
• Validate queries against a staging environment to confirm correct results and performance characteristics.
• Save and deploy the configuration; changes propagate to agent sessions according to the admin center’s publishing model.
• Train agents on the resulting consult/transfer behavior and monitor metrics.

Best practice: test changes first in a non-production environment and engage both service-design and compliance teams when FetchXML queries filter on sensitive attributes (such as locale, customer type, or regulatory flags).

---

Technical considerations and limitations​

This new capability is powerful, but it introduces several operational and technical considerations you must plan for.

• FetchXML complexity and maintainability. FetchXML is flexible, but complex queries can be hard to author and even harder to troubleshoot. Maintain a library of tested queries and add clear comments or naming conventions so future admins understand intent.
• Performance and latency. Consult/transfer candidate lists are typically expected to appear quickly in an agent’s UI. FetchXML queries that are inefficient, or that query large, poorly-indexed datasets, risk adding latency to the consult/transfer flow. Test query performance at expected load.
• Visibility and governance. Changes to consult/transfer queries affect agent workflows and compliance obligations. Lock down who can edit these configurations, use change control, and maintain an audit trail.
• Presence and availability semantics. The consult UI may filter results based on presence (for example, only show online agents). If your FetchXML returns a valid set that includes offline reps, test how presence filtering and FetchXML interplay to avoid unexpected results.
• Interactions with Teams and external transfers. Existing options — like consulting a Teams user or transferring to an external PSTN number — continue to behave as documented. However, if you rely on Teams Phone extensibility or bridged transfers, verify the end-to-end experience when consult candidate lists are restricted.
• Regional and tenant rollout differences. Microsoft’s announcement marks general availability, but some tenants or geographies might see staged activation. Confirm feature availability in your tenant admin center before changing production workflows.
• Logging, reporting, and analytics. Ensure your telemetry captures consult attempts, transfer failures, and consult durations so you can measure the operational impact and tune FetchXML queries accordingly.

If your contact center uses third-party workforce management, UCaaS, or telephony connectors, map out integration points and test end-to-end scenarios—especially for transfers that cross systems.

---

Security, compliance, and privacy implications​

Any change that affects who agents can contact or transfer calls to raises security and compliance questions.

• Controlled exposure of user data. FetchXML queries can and will operate on attributes that might be sensitive. Limit which fields the queries use and who can author them.
• Regulatory routing. For regulated industries, consult/transfer restrictions can be used to keep certain interactions within defined groups (for example, don’t allow EU personal-data calls to be transferred to non-EU reps). Use the configuration to enforce these policies.
• Audit trails and change control. Maintain a versioned change log and require approvals for updates to consult/transfer queries — especially those that affect critical workflows.
• Call recording and transcript retention. Consult conversations may include additional participants; ensure your call-recording and transcription policies cover consult participants and external transfers and that consent requirements are met.

Administrators should engage security and legal teams when drafting FetchXML queries that touch regulated attributes or that could expose personally identifiable information.

---

Operational best practices and rollout checklist​

Implementing consult/transfer customization is a configuration change with human and technical impacts. Use this practical checklist to reduce risk and improve adoption.

• Inventory existing consult and transfer flows.
• Identify business scenarios that benefit most (subject-matter routing, compliance, escalation management).
• Author FetchXML queries in a staging environment and test under load.
• Use descriptive naming conventions and document the intent of every query.
• Create a change-control process that includes service design, compliance, and training teams.
• Train agents on how consult lists will look and when to use consult vs transfer.
• Monitor key metrics: consult attempt rate, consult-to-transfer conversion, transfer success rate, average hold time during consults.
• Iterate rules based on measured outcomes and agent feedback.

These steps help ensure the configuration change improves outcomes rather than introducing friction.

---

How this interacts with related Dynamics 365 Contact Center updates​

The consult/transfer customization arrives alongside and after several other contact-center enhancements that Microsoft has been delivering — notably Teams Phone extensibility, capacity control capabilities, and intent-based routing improvements.

• Teams Phone extensibility: Dynamics 365 Contact Center’s closer integration with Teams Phone means consults and transfers that involve Teams users need to be validated end-to-end. Depending on the voice channel configuration, transfers to Teams users may use bridged calls or new-call semantics; validate these behaviors when consult candidate lists are narrowed.
• Capacity blocking and automated consult selection: Release notes show that Microsoft has been adding capacity-blocking features and automated consult selection logic. Administrators must ensure that FetchXML-driven consult lists and any automated selection features do not conflict; for example, avoid directing consults to agents who are capacity-blocked.
• Enhanced voice experiences and bridging behaviors: The voice experience (enhanced vs legacy) influences transfer semantics; consult and transfer configuration should be validated against the voice experience used by your tenant.

Taken together, these feature threads show Microsoft’s push to make Dynamics 365 Contact Center both more flexible for admins and more intelligent for agents. However, the combination increases the need for comprehensive testing before production rollout.

---

Real-world scenarios and examples​

Below are practical examples of how organizations might use these new configuration options.

• Tiered product support: An enterprise with multiple product lines wants consults to preferentially show subject-matter experts who are certified on the customer’s product. Admins author FetchXML to filter representatives by product-certification attribute and current queue membership.
• Regulated transfers: A financial services firm prevents transfers of certain call types to agents who do not hold a license. The FetchXML query filters reps by a “licensed” boolean attribute and by territory.
• Language-aware consults: A global services organization uses FetchXML to show only representatives with the required language skill and local time-zone availability, improving the chance the consult is useful.
• VIP handling: When a high-value customer is identified on the call, the agent’s UI can use a different consult query (or a higher-priority consult template) that surfaces specially trained VIP reps only.

Each scenario emphasizes how targeted consult/transfer lists can reduce friction and improve first-contact resolution.

---

Risks and potential downsides​

Even with clear benefits, organizations should be mindful of risks:

• Misconfigurations can increase transfers. Overly narrow queries may remove suitable consult targets and force agents into longer routing paths or repeated transfers.
• Operational brittleness. Relying on attributes maintained in other systems (like workforce management) creates coupling; if those feeds lag, consult lists may be inaccurate.
• Skill atrophy. If agents can always consult specialists easily, they may become less empowered to resolve issues themselves. Build training into the rollout plan.
• Complex troubleshooting. When agents report missing consult targets, admins must be prepared to debug FetchXML logic, Dataverse permissions, and presence-filtering interactions.
• Tenant differences and phased availability. If your tenant receives the feature later due to staggered rollout, coordination between teams could be confused.

Prepare rollback plans and feature flags where possible so that changes can be reversed if operational metrics deteriorate.

---

Recommendations for IT and service leaders​

For IT leaders, contact center architects, and operations managers planning to adopt this capability, here are distilled recommendations:

• Treat consult/transfer customizations as a product change: apply release management, acceptance testing, and staged rollouts.
• Start small: pilot specific consult scenarios (like one product line or a VIP routing rule) before broad adoption.
• Build operational dashboards: track the consult conversion rate and transfer success metrics to quantify improvement.
• Enforce governance: restrict who can edit FetchXML queries and require peer review for changes that affect business-critical flows.
• Collaborate with workforce management: align attributes used in queries with WFM data to avoid conflicts.
• Document and train: ensure agents understand the new consult candidate lists and when to escalate or transfer.

These pragmatic steps help ensure the feature delivers efficiency gains instead of operational drift.

---

Troubleshooting quick tips​

If consults or transfers don’t behave as expected, try these steps:

• Confirm the FetchXML returns expected records in the Dataverse query tester.
• Check Dataverse permissions — the admin account must be able to read the attributes used in the query.
• Validate presence filtering: replicate a consult while varying presence states to ensure visibility rules match expectations.
• Test with a simple query first, then add complexity iteratively.
• Review call-routing logs and telemetry for consult events and filters applied.
• Revert to a known-working query as a stop-gap while debugging.

A methodical approach saves time: isolate Dataverse, Copilot admin config, and agent UI steps one by one.

---

What to watch next​

This feature is foundational rather than flashy — it expands configuration control and enables more nuanced consult/transfer behavior without code. After initial adoption we expect the ecosystem to evolve in these directions:

• Pre-built templates and sample queries released by Microsoft partners and the community to accelerate common scenarios (language routing, compliance filtering, VIP routing).
• UI-assisted query builders that let admins create common filters using field pickers instead of hand-editing FetchXML.
• Better analytics surfaced in Dynamics Contact Center dashboards that report consult outcomes and help admins tune queries.
• Integration with AI-based routing where consult/transfer candidate lists are informed by intent detection or predicted resolution probability.

Administrators should also watch for release notes and the admin center for incremental improvements that ease authoring, validation, and governance of FetchXML-driven consults.

---

Conclusion​

Microsoft’s rollout of configurable consults and transfers for Dynamics 365 Contact Center is a pragmatic, admin-focused enhancement that shifts control of consult/transfer candidate selection into the hands of platform teams. By using FetchXML in the Copilot Service admin center, organizations gain powerful declarative control to target the right queues and representatives for consults and transfers — enabling skills-aware routing, compliance controls, and subject-matter handoffs without heavy code changes.
That power comes with operational responsibility: careful testing, governance, performance tuning, and monitoring are essential. For contact centers that take the time to pilot, document, and iterate on these configurations, the payoff should be fewer misroutes, faster resolutions, and a smoother agent experience. For those that rush the change without adequate controls, the opposite — increased transfers, confusion, and brittle operations — is possible.
If you manage a Dynamics 365 Contact Center deployment, treat this capability as a platform improvement worth planning for: pilot it with clear goals, measure the impact, and bake the configuration process into your change-management and training practices.

---

Source: Windows Report https://windowsreport.com/microsoft...nd-transfers-for-dynamics-365-contact-center/

 

[ChatGPT]

Microsoft’s latest tweak to Dynamics 365 Contact Center is small in code but large in operational impact: administrators can now use FetchXML-driven queries to control which queues and representatives appear as consult or transfer targets, a capability that reached general availability on January 26, 2026. ps://mc.merill.net/message/MC1221931)

Background / Overview​

Dynamics 365 Contact Center sits at the center of Microsoft’s push to deliver agentic customer service—an integrated stack that combines Dataverse, Copilot, Copilot Studio, and new connector standards such as the Model Context Protocol (MCP). The platform already includes voice and digital channels, Teams Phone interoperability, intent-based routing, and Copilot-enhanced email and knowledge workflows. The FetchXML consult/transfer enhancement plugs into that stack by allowing admins to declare routing filters using the native Dataverse query language rather than emberouting code.
At a practical level, the feature gives administrators four configurable scenarios in the Copilot Service admin center’s “Consult and transfer” page:

• Consult to queue
• Consult with a representative
• Transfer to a queue
• Transfer to a representative

When configured, those queries dynamically tailor the candidate lists agents see during consult and transfer flows, enabling skills-aware handoffs, compliance-aware routing, and targeted subject-matter consults without deploying changes to the routing ent posted Message Center note MC1221931 announcing the feature, which Microsoft indicates reached GA on January 26, 2026.

---

Why FetchXML matters: Declarative routing, not code​

FetchXML and Dataverse: the natural fit​

FetchXML is the platform-native, declarative query language used throughout Dataverse. Because Dataverse already holds user records, queue membership, custom attributes (skills, certifications, compliance flags), and partner-extended fields, exposing consult/transfer logic as FetchXML queries gives administrators direct access to the same data model 365. That means organizations can target candidate lists by nearly any attribute that exists in Dataverse—without writing or deploying custom routing code.
This is a pragmatic move: many enterprise contact centers maintain workforce attributes in external systems or in partner custom fields inside Dataverse. A declarative query surface reduces the friction of mapping those attributes into routing decisions and lowers maintenance costs because changes are published through the admin center instead of requiring development cycles. Microsoft’s Release Wave 2 2025 documentation places these kinds of admin-focused productivity and governance features squarely in the product roadmap for October 2025–March 2026.

Operational benefits​

• Targeted handoffs: Show only certified or product-line specialists during consult.
• Compliance-aware routing: Prevent transfers that would violate licensing or data residency rules by filttributes.
• Faster iterations: Update query logic in hours via the admin center instead of weeks of developer time.
• Integration-friendly: Use custom partner fields maintained in Dataverse without custom middleware.

---

Technical implementation and constraints​

How admin configuration is expected to work​

Administrators authenticate to the Copilot Service admin center, navigate to the Consult and transfer configuration page, and provide a FetchXML query for each of the four scenarios. Queries return queues or user records that willuring consult or transfer actions. Typical adoption guidance is to author and validate queries in non-production, test for performance under load, then publish to production while maintaining change control.
A recommended configuration workflow commonly looks like this:

• Inventory the consult and transfer use cases you want to control.
• Draft FetchXML queries in a staging environment and validate returnede query latency and refine indexes in Dataverse as needed.
• Apply role-based restriction to who can edit these queries.
• Train agents on the new consult/transfer candidate lists.

Performance and presence semantics​

Agent UX expectations are strict: consult candidate lists must appear quickly. Complex FetchXML that scans large, unindexed datasets can add latency to the consult/transfer flow. Additionally, presence filtering (for example, showing only online agents) still operates as partdmins must test how FetchXML results interact with presence- and capacity-blocking behaviors to avoid surprising results—such as offline agents appearing as targets.

Security, permissions, and governance​

Because FetchXML queries read tenant Dataverse data, Dataverse permissions must allow the admin account performing the query to read the referenced attributes. Audit trails, versioning, and change-control policies are critical—especially if queries filter on regulated attributes (location, certification, VIP stcommunity guidance both recommend locking down edit permissions and requiring peer review for updates that change routing for high-impact flows.

---

Practical scenarios: Where this will make the biggest difference​

1) Regulated industries: certification and territory controls​

A financial services or healthcare contact center can use FetchXML to surface only licensed representatives for regulated case transfers to agents within a specific legal jurisdiction. This avoids ad hoc agent decisions that might breach compliance.

2) Language and timezone-aware consults​

Global service operations can filter consult lists to show only agents who speak the customer’s language and are within ness hours, improving the probability a consult will be effective and avoiding unnecessary escalation.

3) VIP or product-specialist routing​

VIP customers can trigger a different FetchXML template that surfaces specially trained VIP reps, or rts, ensuring high-value calls get prioritized handoffs and reducing handle time.

---

AI-driven capabilities in Release Wave 2: how they tie in​

FetchXML-driven consults are one configuration-level improvement. The broader Release Wave 2 2025 includes multiple AI agent features that change how consults, transfers, and routing are informed:

• Customer Knowledge Management Agent: Generates or updates knowledge base articles in near real-time from resolved cases and conversation transcripts—helpful for reducing repeat escalations.
• Case Management Agent: Automatically creates and populates cases when chats or emails arrive and suggests the right internal expert.
• Intent-based routing: Uses generative AI to classify message intent (beyond keywords) and match that intent to agent groups with specific skills.
• Copilot-powered template recommendations: Copilot suggests email templates and can run embedded prompts when templates are selected.

These AI agents and routing capabilities are delivered as part of the Wave 2 cadence (October 2025–March 2026) and are already documented in Microsoft’s release plan pages. Administrators should consider how FetchXML consult filters and AI intent-based routing interact—there's opportunity for synergy (e.g., intent determines which FetchXML template to use) but also risk if rules conflict (e.g., intent suggests a queue that FetchXML filters out).

---

Extensibility: Model Context Protocol (MCP) and third-party agents​

Microsoft’s Model Context Protocol (MCP) server standard lets organizations connect external AI agents (for example, Claude, custom Copilot Studio agents, or other third-party models) into Dynamics 365 Customer Service. MCP servers expose a set of tools—actions such as create case, list accounts, or draft emails—that agents can call under tenant-controlled permissions. This enables hybrid AI strategies where Microsoft’s built-in agents work alongside third-party or custom agents to execute actions inside Customer Service.
MCP is powerful but introduces new security considerations: it becomes an attack surface if misconfigured. Independent reporting on MCP adoption highlights prompt injection and server misconfigurations as real risks; enterprise teams must apply strict authentication, allowed-client lists, and robust audit logging when enabling MCP integrations. Microsoft documentation for MCP also emphasizes administrative control over allowed clients and preview-status caveats for some MCP server implementations.

---

Workspace and supervisor tooling improvements​

Release Wave 2 includes agent workspace improvements that support the new consult/transfer features and AI agents: session persistence across browser refreshes, multisession support for custom model-driven apps, and supervisor bulk actions in Omnichannel real-time analytics. These features reduce productivity loss from transient connection issues and give supervisors the tools to act quickly dor example, reassigning dozens of conversations with a single command. These operational improvements pair well with targeted consult listact centers remain responsive during peaks.

---

Risks, caveats, and governance checklist​

FetchXML-driven consults are high-value but not risk-free. Implement witons:

• Avoid over-narrow queries: If queries become too restrictive, agents may be left with no viable consult targets and will escalate or create inefficient workarounds.
• **Monitoy latency can degrade UX. Test queries under realistic load and add Dataverse indexing where necessary.
• Govern edits and change control: Limit who can author or publish FetchXML queries; track changes with versioni- Test presence and capacity interactions: Validate consult lists in voice flows that include Teams users, bridged transfers, or external PSTN calls.
• Audit and compliance: Ensure queries that filter on sensitive attributes are reviewed by compliance and legal teams. Maintain audit logs for consult/transfer configuration changes.

Operational best practices include piloting with a single product line or queue, building dato-transfer conversion and transfer success rate, and training agents on the new consult/transfer behavior.

---

Change management: rollout checklist and troubleshooting quick tips​

A practical rollout checklist:

• Inventory current consult/transfer flows and prioritize scenarios to pilot.
• Build and tesa sandbox.
• Validate results using Dataverse query tools and monitor latency.
• Apply RBAC to the Copilot Service admin center configuration area.
• Staged rollout and agent training with rollback plans.

Troubleshooting quick tips:

• Confirm the FetchXML returns expected records in Dataverse query tester.
• Check Dataverse permissions for any attributes referenced by the query.
• Test presence-filtering interactions by toggling presence states.
• Revert to a simple, known-good query while debugging.

---

Industry context: measured progress, not instant transformation​

Analyst coverage and Microsoft’s own release planning frame 2025–2026 as a period of foundational work for AI in custoan instant, headline-grabbing transformation. Microsoft was named a Leader in Gartner’s 2025 Magic Quadrant for CRM Customer Engagement Center, underscoring market confidence in its platform maturity, while Forrester forecasts 2026 as a year where organizations do the heavy lifting required to operationalize AI responsibly. Those external perspectives align with Microsoft’s incremental, admin-focused enhancements like FetchXML consults: useful, pragmatic pieces of a much larger operational puzzle.
Importantly, customer-case metrics quoted in vendor materials (for example, percentage improvements rcase studies) should be treated as vendor-provided signals and verified in your own pilots and contractual KPIs before relying on them for procurement decisions. Microsoft’s docr stories provide directionally positive results, but independent validation remains essential.

---

What administrators should do next (prac)​

• Plan a pilot: Start with one product line, one regulatory scenario, or a VIP routing use case. Measure consult-to-transfer convess rate, and average handle time.
• Govern the config: Restrict edit rights in the Copilot Service admin center and require peer review for production changes. Maintaation artifacts.
• Test end-to-end: Validate consult/transfer flows that involve Teams Phone, bridged transfers, and any UCaaS connectors your tenant uses.
• Monitor telemetry: Add consult events and consult latency to your operational dashboards so you can detect regressions quickly.
• Align workforce data: Ensure workforce management and back-office systems sync the attributes that FetchXML filters upon to avoid stale or incorrect consult lists.

---

The longer view: where this fits in Microsoft’s agentic strategy​

FetchXML-driven consults are a conservative but crucial piece of Microsoft’s broader agentic architecture: they emphasize control, governance, and incremental automation rather than replacing human judgment. Paired with MCP-enabled agents, Copilot-powered suggestions, and workspace improvements, administrators gain more levers to optimize routing and workflows—but with more responsibility to manage security, governance, and human-in-the-loop oversight. If implemented thoughtfully, declarative consult/transfer rules reduce time-to-change and lower TCO for routing logic; if rushed, they risk adding brittleness to the contact center.

---

Conclusion​

Microsoft’s FetchXML-driven consult and transfer customization is a classic product move that prioritizes operational control over novelty. By exposing consult/transfer candidate selection as a declarative, Dataverse-native surface in the Copilot Service admin center, organizations gain flexible, rapid, and auditable routing controls that align with skills, compliance, and business rules—without embedding logic in custom routing code. The feature’s GA on January 26, 2026 is documented in Microsoft’s Message Center and mirrors Release Wave 2’s strategy of incremental, governance-minded AI improvements. Administrators who pilot carefully, govern changes, and integrate these rules with broader AI-driven routing and MCP-enabled agents stand to reduce misroutes and improve first-contact resolution; those who rush adoption without adequate testing and oversight risk introducing operational fragility.
For Dynamics 365 Contact Center teams, the practicahtforward: author a small set of FetchXML templates in staging, validate results and latency, and run a controlled pilot. Measure the real-world effect on consult success and hold times—then iterate. The payoff is not headline AI transformation but a meaningful reduction in friction where it matters most: the moment an agent decides whether to consult or transfer a live customer.

---

Source: WinBuzzer Microsoft Enhances Dynamics 365 With FetchXML Agent Routing - WinBuzzer