Implementing Dynamics 365 Contact Center: channels, routing and rollout

Why Contact Center projects are different

Most Dynamics 365 projects I lead are about data, processes and forms. A contact center project adds three things that change the rhythm of the work: telephony, real-time routing and people who are measured by the minute. When a chat lands with the wrong team or a call waits in a queue nobody is subscribed to, the customer notices immediately. That makes Dynamics 365 Contact Center one of the most rewarding implementations to get right, and one of the least forgiving to get wrong.

This article walks through how I approach a Contact Center implementation: choosing the right deployment model, setting up voice and digital channels, designing unified routing, preparing the representative workspace and Copilot, and rolling it out in phases. Start with the official Dynamics 365 Contact Center overview.

Embedded, standalone or inside Customer Service: Decide first

Microsoft documents Dynamics 365 Contact Center in three flavors, and most configuration and feature articles state explicitly which of them they apply to. This is the first decision to make, because it determines where your case data lives and which app your representatives open in the morning. If you already run Dynamics 365 Customer Service, the third flavor is almost always the natural choice: channels, unified routing and Copilot run inside Customer Service, and conversations, cases, knowledge and customer records all live in the same Dataverse environment. The other two are:

Contact Center – embedded: the conversation widget is embedded in a non-Microsoft CRM such as Salesforce or ServiceNow. Representatives keep working in that CRM, connectors sync contacts and accounts, and Microsoft handles routing, voice and AI. Microsoft provides connectors for Salesforce and ServiceNow plus a connector for any other CRM. This suits organizations that want Microsoft's contact center capabilities but keep their case management elsewhere.
Contact Center – standalone: Copilot Service workspace runs as its own app on Dataverse, without the case management of Dynamics 365 Customer Service. This suits organizations that want a contact center on the Microsoft platform without adopting the full Customer Service application.

Do not underestimate the integration effort of the embedded option. Customer identification, record lookups and writing back interaction history to the external CRM are integration work with their own testing, security and support model. Budget for them as such.

Coming from the former Omnichannel for Customer Service

If you implemented Omnichannel for Customer Service in recent years, much of Contact Center will feel familiar. Microsoft's documentation now presents the channel and routing capabilities of Customer Service under the Contact Center name: the introduction to Dynamics 365 Contact Center lives at the URL that used to describe Omnichannel for Customer Service, and the same unified routing, workstreams, queues and capacity profiles power both. In other words, for most existing customers this is an evolution of the product and its licensing, not a reimplementation from scratch.

Check your licenses and terminology first

Before planning any technical migration, confirm with your licensing partner which Contact Center or Customer Service licenses cover the channels and AI features you need. Also expect renamed apps and terms: the representative app is now called Copilot Service workspace (previously Customer Service workspace), the admin app is Copilot Service admin center (previously Customer Service admin center), and Microsoft now calls human agents "service representatives" and bots "AI agents".

What to review in an existing omnichannel environment

Apps in use: representatives must use Copilot Service workspace to receive work through unified routing. Custom copies of the workspace app or Unified Service Desk are not supported for this, so plan the move if you still run them.
Legacy routing: if you still route cases with basic routing rules or custom workflows, move to record routing in unified routing so that cases and conversations share one assignment model.
Voice workstreams and bots: Microsoft documents a migration path for existing voice workstreams so they work with the newer voice-enabled Copilot Studio agents. Review it before rebuilding your IVR.
Customizations: inventory session templates, notification templates, macros and productivity pane scripts. They usually carry over, but they are also the first thing to break when you change apps.

Voice and digital channels

Channels are provisioned in Copilot Service admin center under Customer Support > Channels. Which checkboxes you can tick depends on your licenses. The available channel families are chat, voice, SMS, social messaging and Microsoft Teams.

Voice

The voice channel is built on Azure Communication Services and gives representatives inbound and outbound PSTN calling inside the workspace, with call controls, transfers, consults, voicemail, live transcription and sentiment analysis. The IVR is a Copilot Studio agent attached to the voice workstream, built with the same tooling as a chat bot.

Telephony is where the external dependencies are. In the admin center you can only acquire US phone numbers; for other countries, including Belgium, you buy numbers in Azure Communication Services and sync them, or bring your own carrier through Azure direct routing. Decide early which route you take and involve whoever owns your current phone numbers. Porting Belgian numbers and coordinating a cut-over with the old platform takes calendar time that no amount of configuration can shorten.

Digital channels

Digital channels are quicker to stand up, but each has its own behavior that affects routing design:

Live chat: a widget on your website or portal, with pre-chat surveys that feed routing (language, topic, logged-in customer). Persistent chat lets a conversation continue across sessions.
SMS: asynchronous by nature. Customers reply hours later, so the conversation sits in a waiting state and comes back to the queue based on last interaction time.
Social and WhatsApp: also asynchronous, with the provider's own rules on templates and response windows. Agree with marketing and legal who owns these accounts before connecting them.
Microsoft Teams: useful for internal service desks such as IT or HR support, where the "customers" are your own employees.

Designing unified routing

Unified routing is the heart of the product and the part that deserves most of your design time. It works in two stages: classification adds information to the incoming work item (skills, priority, customer tier, language) and assignment picks the best-suited representative based on skills, presence and capacity. Read the unified routing overview and then design on paper before you click anything. The building blocks are:

Workstream: the container per channel and type of work, with its allowed presences, capacity requirements and work distribution mode (push or pick).
Queue: the group of representatives who can take a type of work, with an assignment method and an operating hours calendar.
Classification rules: conditions on the work item and related records that set skills, priority or other attributes before the item is routed.
Route-to-queue rules: an ordered rule set that sends the work item to the right queue. Always define a fallback queue that somebody actually monitors.
Capacity profiles: how much concurrent or daily work a representative can take per type, and whether a phone call blocks other channels. Microsoft recommends using either capacity profiles or capacity units, not both.
Presence: Available, Busy, Do not disturb and custom statuses. Each workstream lists which presences may still receive work.

Choosing an assignment method

Every queue gets an assignment method. The built-in options cover most needs, and you can define custom prioritization and assignment rulesets when they do not. The assignment methods documentation explains the exact tie-breaking logic. In practice:

Method	How it assigns	When I use it
Highest capacity	To the matching representative with the most available capacity; round robin on ties.	Chat-heavy teams where representatives handle several conversations at once.
Advanced round robin	Rotates through matching representatives per queue, based on their last assignment.	When fair distribution matters more than raw throughput.
Least active	To the representative who has been idle longest since releasing capacity on voice or messaging work.	Voice queues, where back-to-back calls for the same person are the main complaint.
Custom	Your own prioritization rules (for example VIP first) and assignment rules.	Only when the built-in methods demonstrably fall short; every custom rule is something to test and explain.

Keep the routing model explainable

A good test: can a team lead explain, without opening the admin center, why a specific chat went to a specific person? If not, you have too many queues, too many skills or too many custom rules. Start with a handful of queues and a small, well-defined skill set, and add complexity only when reporting shows you need it.

The representative workspace

Representatives work in Copilot Service workspace, a multisession app where every accepted conversation or opened case becomes a session, each with its own tabs. Microsoft documents a limit of nine sessions and ten tabs per session, which is more than any representative should juggle anyway.

Most of the user experience is configured rather than built:

Session templates: define which page opens when a conversation is accepted, for example the customer profile with the active case next to it.
Notification templates: control what the representative sees in the incoming-work toast, including pre-chat answers and customer name.
Customer identification: record identification rules match the conversation to a contact or account automatically, so the representative does not start with a search.
Macros and scripts: agent scripts guide representatives through regulated or complex conversations, and macros automate repetitive steps such as creating a case from the conversation.

Copilot assistance for representatives

Copilot is where Contact Center differs most from what Omnichannel for Customer Service offered a few years ago. The capabilities you can enable in Copilot Service admin center include:

Conversation summaries: a summary when a conversation is transferred or wrapped up, so the next representative does not ask the customer to repeat everything. Case summaries are added if you run Dynamics 365 Customer Service.
Ask a question: representatives ask Copilot in the help pane and get answers grounded in your knowledge sources.
Draft a response and compose email: suggested chat replies and emails that the representative reviews and edits before sending.
Translation: representatives can translate Copilot-generated responses into their preferred language, which is useful in a multilingual country like Belgium.

The quality of these features is limited by the quality of your knowledge base. If your knowledge articles are outdated, duplicated or written for internal experts, Copilot will confidently repeat that. Plan a knowledge clean-up in the project and, if you run Dynamics 365 Customer Service, use its knowledge filters so that Copilot draws on the right articles for each product or brand.

Treat AI features as a governed change

Involve your data protection officer before enabling generative AI features, check whether any feature requires data movement across regions in Power Platform admin center, and tell representatives clearly that suggestions must be reviewed. Pilot with a small team and collect their feedback before enabling Copilot for everyone.

Recording, privacy and EU considerations

Call recording and transcription are configured per voice workstream, with automatic or manual start and the option to pause and resume. Microsoft is explicit that many jurisdictions regulate call recording and may require consent, and that compliance is your responsibility. Read the guidance on call recording, transcription and real-time translation and then make the legal decisions before the technical ones. For Belgian and other EU organizations, I check at least the following with the customer's legal or privacy team:

Legal basis and notice: how callers are informed about recording and transcription, and what the IVR announces before a representative picks up.
Retention: how long recordings, transcripts and conversation records are kept, and how they are deleted when that period ends.
Data residency: in which region the environment and its channel resources are hosted, and whether any enabled feature moves data outside that region.
Employee monitoring: supervisor monitoring, analytics and recording also concern your own staff. Microsoft states that capacity and performance features are not intended for employment decisions; involve HR and, where applicable, employee representatives early.

Reporting on conversations

Contact Center ships with real-time and historical analytics dashboards for supervisors, and you should start there. For ad-hoc checks during testing, I query the Conversation table (msdyn_ocliveworkitem) directly. This FetchXML counts last week's voice conversations per queue and status reason:

<fetch aggregate="true">
  <entity name="msdyn_ocliveworkitem">
    <attribute name="activityid" alias="conversations" aggregate="count" />
    <attribute name="msdyn_cdsqueueid" alias="queue" groupby="true" />
    <attribute name="statuscode" alias="status" groupby="true" />
    <filter>
      <condition attribute="createdon" operator="last-x-days" value="7" />
      <!-- msdyn_channel is a multi-select choice; 192440000 = Voice call (PSTN voice channel) -->
      <condition attribute="msdyn_channel" operator="contain-values">
        <value>192440000</value>
      </condition>
    </filter>
  </entity>
</fetch>

During user acceptance testing, a query like this quickly shows whether work ends up in the fallback queue or stays in Open status longer than expected, which usually points to a routing rule or presence configuration issue.

ALM for Contact Center configuration

Routing configuration is not just customization in a solution, and this is where many projects lose time. Workstreams and channel settings can travel in solutions, but queues, capacity profiles and skill-based routing rulesets need the Configuration Migration tool, in a specific order. Follow Microsoft's guide to migrate channel configurations using solutions and script it so every environment is built the same way:

# 1. Routing configuration data (queues, capacity profiles,
#    skill-based routing rulesets) via the Configuration Migration tool.
#    The schema files are created once with the Configuration Migration tool.
#    pac data runs only in the Windows (.NET Framework) build of the PAC CLI.
pac auth create --name dev --environment https://contoso-dev.crm4.dynamics.com
pac data export --schemaFile .\config\queues-schema.xml --dataFile .\out\queues.zip --overwrite

pac auth create --name test --environment https://contoso-test.crm4.dynamics.com
pac data import --data .\out\queues.zip

# 2. Workstreams and channel settings via a solution
pac auth select --name dev
pac solution export --name ContosoContactCenter --path .\out\ContosoContactCenter.zip --managed

pac auth select --name test
pac solution import --path .\out\ContosoContactCenter.zip

Account, channel provider, agent configuration, and AI and analytics settings are out of scope for this migration. Phone number records travel in the solution, but the Azure Communication Services connection and number sync have to be redone per environment; document these steps in a runbook. The documented order for the Configuration Migration tool is session and notification templates, then rulesets, capacity profiles and queues, and the workstream step also needs it for quick replies, tags and system messages. Note that pac data is only available in the .NET Framework (Windows) build of the Power Platform CLI.

A phased rollout plan

I never recommend a big-bang go-live for a contact center. This is the sequence I typically propose:

Discovery and design: map contact reasons, volumes per channel, opening hours, languages and skills; choose between embedded, standalone and Customer Service; agree on the legal position on recording and AI.
Foundation: environments, security roles, channel provisioning, telephony and number planning, and the ALM scripts for routing configuration.
First channel with a pilot team: usually live chat or record routing for cases, because the impact of mistakes is smaller than on voice.
Voice: IVR agent, voice queues, recording settings and a carefully planned number cut-over, ideally outside peak periods.
Copilot features: enable summaries and Ask a question for the pilot team, review knowledge quality, then expand.
Scale and optimize: add teams and channels, tune assignment methods and capacity based on real reporting, and hand over to a support team that understands routing.

Common pitfalls

Too many queues on day one: every queue needs members, a calendar, overflow handling and someone watching its reports.
No fallback queue: work items that match no rule must land somewhere visible, not disappear into a queue nobody is subscribed to.
Presence discipline: routing is only as good as representatives' presence. Train it, and configure what happens when work is rejected or times out.
Testing only the happy path: test transfers, consults, out-of-hours behavior, customers who abandon, and representatives who log off mid-conversation.
Manual configuration per environment: hand-built queues in test and production drift apart within weeks. Script the migration from the start.
Ignoring supervisors: supervisors need dashboards, monitoring and the authority to reassign work. Involve them in design, not just in training.

Conclusion

Dynamics 365 Contact Center brings voice, digital channels, unified routing and Copilot together on the Dataverse platform that many CE teams already know. The technology is mature; success depends on a clear routing model, a realistic telephony plan, solid ALM and a phased rollout that lets real usage shape the configuration. Get those right and your representatives spend their time helping customers rather than fighting the tool.

Need help with your Dynamics 365 project?

I help organizations design and roll out Dynamics 365 Contact Center, from routing design and voice to Copilot and ALM.

Implementing Dynamics 365 Contact Center: Channels, routing and rollout