Integrating Dynamics 365 with Twilio for SMS and voice

Twilio comes up in Dynamics 365 projects for two reasons. One is that Dynamics 365 Customer Service's own SMS channel supports Twilio as a provider, so contact centres already use it under the hood. The other is that everywhere else in Dynamics 365, there is no built-in SMS or voice at all, and Twilio's API is the quickest way to get a text message or a phone call out of a business process. The patterns are different enough for those two cases that they are worth separating.

Inside Customer Service: Twilio as a channel provider

Customer Service's omnichannel capabilities let agents handle SMS conversations in the agent workspace, with routing, queues, and transcripts like any other channel. Twilio is one of the supported SMS providers: you register a Twilio number and credentials in the channel configuration and the platform handles the rest. Agents never see Twilio. See WhatsApp and SMS channels in Customer Service for the channel setup and licensing.

For voice, Microsoft's own Azure Communication Services is the native path, and Twilio Voice is not a supported provider for the omnichannel voice channel. Organisations with a Twilio Flex contact centre generally keep Flex and integrate it with Dynamics 365 through Twilio's CRM integration or a custom agent desktop, which is a different project. Our omnichannel voice guide covers the native option.

If the requirement is agents having two-way SMS conversations with customers, use the channel. Do not build it.

Outside Customer Service: Twilio as an API

Everything else is process-driven messaging: an appointment reminder from Field Service, a delivery notification from an order, a one-time code from a portal, a "your quote is ready" text from Sales. None of these need an agent, and all of them are an API call.

Power Automate with the Twilio connector. A flow on a Dataverse event sends an SMS with the connector's send action. This covers most notification scenarios in an afternoon. Keep the message template in an environment variable or a Dataverse configuration table, not hard-coded in the flow.

Azure Function calling the Twilio API. For volume, for messaging services with sender pools and compliance features, for scheduled sends, and for anything that needs retry logic and logging. Also the route when messages originate from Business Central or F&O, where a flow or a Logic App triggered by a business event calls the function.

Inbound replies. Twilio delivers inbound SMS to a webhook you configure on the number. An HTTP-triggered flow or a function receives it, matches the sender's number to a contact, and creates an activity or updates a record ("reply YES to confirm" on a work order). Matching by phone number is unreliable enough that the message should carry a reference the reply can echo.

Click-to-call and call logging. A PCF control or a canvas app on the contact form that initiates a Twilio Voice call from the browser, then writes a phone call activity with duration and outcome when it ends. Twilio Voice's JavaScript SDK makes the call; your control handles the Dataverse side. This is the classic light CTI pattern for Sales teams that do not have a contact centre and do not want one.

Consent and regulation

SMS is regulated more tightly than email in most jurisdictions, and the rules differ by country. Marketing messages need explicit opt-in; transactional messages are usually permitted but must offer a way to stop; sending windows are restricted in some places. Twilio enforces some of this through its messaging service compliance features and through registration requirements for sender IDs and short codes, which take time to obtain and should be started early in the project.

Dynamics 365 must hold the consent state and honour it. A contact's SMS consent is a field, the send flow checks it, and a STOP reply updates it. Customer Insights - Journeys has its own consent model for SMS; if it is in use, it should own the consent record and everything else should read from it.

Cost control

Every message costs money and a runaway flow can send thousands. Put a daily send limit in the function or the flow, alert when it is approached, and never trigger a send from a bulk data update without a filter that excludes records touched by the update itself.

What breaks in practice

Numbers stored in Dataverse in inconsistent formats, so half the sends fail; normalise to E.164 on save. Replies from a number that matches several contacts. Sender registration that was not started early enough, so go-live sends from an unregistered number and gets filtered. Twilio credentials in a flow's action rather than a connection or Key Vault; see Dataverse secrets and Key Vault.

Stability verdict

Twilio's API is as stable as any in this space, and the Customer Service channel integration is supported and maintained by Microsoft. The flow-based notification pattern is stable at low volume and should become a function at high volume. The parts that move are regulatory: sender registration rules and consent requirements change, and the integration needs an owner who tracks them.