Microsoft recommends its own voice channel first — and sometimes that is the right answer. Dynamics 365 Contact Center ships a first-party voice channel, so the obvious question for anyone already on Dynamics is why they would put a different contact centre underneath it. This page sets out what Microsoft’s own voice channel requires, what it documents as its own limits, and where a third-party contact centre with a CTI connector still makes more sense. We build one of those connectors, so read the last section with that in mind; everything about Microsoft’s product below is linked to Microsoft’s own documentation rather than asserted.
There are two supported ways to get voice into Dynamics 365, and they are not variations of one another.
Microsoft’s first-party voice channel. The telephony is part of the product. Calls arrive through Microsoft’s stack, the agent works in the Dynamics workspace, and routing, recording and transcription are Microsoft features configured in the Copilot Service admin centre.
A third-party contact centre with a CTI connector. The contact centre stays where it is — Amazon Connect, in our case — and a connector built on Microsoft’s Channel Integration Framework 2.0 embeds the softphone in the agent workspace. The call is handled by the contact centre; Dynamics gets the screen-pop, the logging and the context.
This is the part that decides the project for most organisations with existing telephony contracts. Microsoft’s voice channel can use your own carrier, but the documented path is Azure Communication Services direct routing, which requires a certified Session Border Controller connected to an Azure Communication Services resource, with numbers in E.164 format.
That is a perfectly reasonable architecture. It is also a piece of network infrastructure somebody has to own, certify and keep patched, and it is worth costing honestly before it turns up late in an implementation plan.
These are not criticisms invented by a competitor — each is stated in Microsoft’s documentation, and each has bitten a real project somewhere.
Microsoft supports third-party telephony deliberately rather than grudgingly, and documents how to configure it. Its own guidance is to consider the first-party voice channel first; the framework exists for when that is not the right fit. In practice that is four situations.
You already run the contact centre. If Amazon Connect is live, the queues are built and the reporting is trusted, replacing the contact centre to gain a CRM integration is a large project to solve a small problem. The connector is the smaller change.
The contact centre serves more than Dynamics. Plenty of organisations route to teams that never open the CRM. A contact centre that only knows how to be a Dynamics feature is a poor fit for that estate.
Data residency is contractual. With Amazon Connect the instance, the recordings and the reporting stay in the AWS account and region you choose. Where an onshore obligation is written into a contract rather than preferred, being able to name the region matters.
The commercial models differ in shape. One is licensed per user, the other is consumption-based. Which is cheaper depends entirely on how many agents you have and how busy they are, and both vendors change their pricing, so price them from current quotes rather than from any comparison article — this one included.
Channel Integration Framework 2.0 is for the multi-session apps — Omnichannel for Customer Service and the Copilot Service workspace. If your users are in a single-session app today, that is a Dynamics-side change to scope before anyone talks about telephony. Microsoft sets out the difference between the two framework versions.
A large share of people searching for a Dynamics and Amazon integration are not after telephony at all — they want Amazon marketplace orders, inventory or fulfilment flowing into Dynamics, or data moving between Dynamics Finance and Operations, NAV or GP and AWS. That is a different project with different tools and usually a different department. We have set the options out beside each other on the Amazon Connect Dynamics 365 connector page, under “Which Dynamics 365 and Amazon project are you actually doing?”, so it can be ruled in or out quickly.
ProUCX builds the Amazon Connect CTI connector for Dynamics 365 as a Channel Integration Framework 2.0 provider. That is our interest in this comparison and we would rather declare it than have it inferred. If Microsoft’s first-party voice channel suits your estate, use it — it is a capable product and it is one less vendor. If you already run Amazon Connect, serve more than the CRM, or have a residency obligation in writing, the connector is the smaller and more reversible change. Details, setup and pricing are on the connector page.
Yes. It ships a first-party voice channel, so calls can arrive through Microsoft’s own stack rather than a separate contact centre. Bringing your own carrier instead is supported through Azure Communication Services direct routing.
Yes, through Azure Communication Services direct routing. Microsoft’s documentation requires a certified Session Border Controller connected to an Azure Communication Services resource, with phone numbers in E.164 format. It is a supported path, but it is network infrastructure somebody has to own and maintain.
Yes. Microsoft’s Channel Integration Framework 2.0 exists for exactly that, and supports third-party telephony providers in the multi-session apps — Omnichannel for Customer Service and the Copilot Service workspace. Microsoft’s own guidance is to consider its first-party voice channel first.
Not over Azure direct routing. Microsoft documents that the voice channel does not support emergency calling when Azure Communication Services direct routing is used, which is worth raising early because it is usually a compliance question rather than a technical one.
No. Microsoft’s documentation states that native Teams phone numbers cannot currently be brought into the voice channel. Organisations that assume their Teams numbers carry straight across are usually surprised by this.
Microsoft supports contextual transfer from a non-Microsoft IVR, but documents that call records and transcriptions from that part of the call are not available to service representatives. If the IVR leg matters to your quality or compliance review, check that before designing around it.
They are priced on different bases — one licensed per user, the other consumption-based — so a list-price comparison misleads. A small team handling heavy volume and a large team handling light volume reach opposite conclusions from the same rate cards, and both vendors change their pricing. Price both from current quotes rather than from any comparison article, including this one.