Microsoft Dynamics 365 F&O and Twilio integration

What moves between them

The flow runs one direction in substance: Dynamics events drive Twilio messages. ml-connector listens for the Dynamics business events you choose, such as a vendor invoice posted, a vendor payment posted, a purchase order confirmed, or a workflow step completed, and for each one it sends an SMS or places a voice call through Twilio to the mapped recipients. Because the business event payload is only a stub, ml-connector first calls back to the Dynamics OData API to retrieve the amount, vendor, or document number that goes into the message text. Twilio then pushes delivery status callbacks, queued through sending, sent, delivered, undelivered, or failed, which ml-connector records against the originating Dynamics record. No financial data is written into Twilio because it has no place to store it. Where business events are not activated for a category, a scheduled OData poll on the relevant entity stands in.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Dynamics side it obtains and refreshes an Entra ID OAuth 2.0 client-credentials Bearer token before each hourly expiry, scoped to the environment host, and accepts the full tenant-specific URL per customer since Dynamics publishes no shared base address. Business events reach the connector as plain JSON over HTTPS with no signature header, so the endpoint URL is secured by TLS 1.2 or later and each event is deduplicated on its ControlNumber, which is unique but non-sequential, before any message fires. Since the payload is a stub, ml-connector reads the full record over OData to build the alert. For Twilio it sends the API Key SID and secret as HTTP Basic Auth, posts message and call requests as form-encoded bodies rather than JSON, and normalizes every destination number to E.164 with the plus prefix. Twilio has no idempotency-key header, so a stable jobId derived from the Dynamics ControlNumber stops the same alert being sent twice on a re-read or replay. Inbound Twilio status callbacks are validated against the X-Twilio-Signature HMAC-SHA1 using the Auth Token before they are trusted. Dynamics OData returns 429 with a Retry-After header under service protection limits, and Twilio returns 429 on concurrency limits, so both directions back off with exponential delay and jitter. Every notification carries a full audit trail and can be replayed if a send fails.

A real-world example

A mid-sized manufacturer with roughly 400 staff runs Microsoft Dynamics 365 F&O for procurement and finance across two plants, and posts several hundred vendor invoices a week. Before the integration, approvers only saw pending workflow documents when they happened to open the ERP, so high-value invoices sat past their approval window, and a confirmed purchase order to a critical supplier went unnoticed by the receiving team. With Microsoft Dynamics 365 F&O and Twilio connected, an invoice above the approval threshold texts the responsible manager the moment its workflow step fires, a confirmed purchase order alerts the plant buyer, and each message is logged against the document with its Twilio delivery status. Approvals happen the same day, the right people are notified within minutes, and there is a record of who was contacted and whether the message was delivered.

What you can do

• •Turn Dynamics business events, such as a posted vendor invoice or a confirmed purchase order, into SMS or voice alerts through Twilio.
• •Read the full Dynamics record over OData to populate alert text, since the business event payload is only a stub.
• •Record Twilio delivery status, from queued through delivered or failed, against the originating Dynamics document.
• •Gate a sensitive Dynamics action with a Twilio Verify one-time passcode where stronger confirmation is needed.
• •Bridge Entra ID OAuth 2.0 and Twilio HTTP Basic Auth, deduplicating events on ControlNumber and validating Twilio callbacks with HMAC-SHA1.

Questions

Does any financial data move from Microsoft Dynamics 365 F&O into Twilio?

No. Twilio is a communications platform with no vendor, invoice, payment, or GL objects, so there is nowhere to post financial records. The integration reads business events from Dynamics and uses Twilio only to deliver SMS and voice notifications and to report whether they were received.

How does the integration know when to send a message?

Dynamics dispatches a Business Events payload to the connector when an activated event occurs, such as a vendor invoice posted or a workflow step completed. Because that payload is a lightweight stub, ml-connector calls back to the Dynamics OData API to retrieve the full record before composing the message. Where a category has no event activated, a scheduled OData poll on that entity stands in.

How are duplicate events and Twilio webhooks handled?

Dynamics business events carry no signature header and do not guarantee delivery order, so each event is deduplicated on its unique ControlNumber before a message fires, and the endpoint is secured by TLS 1.2 or later. Twilio offers no idempotency-key header, so ml-connector assigns a stable jobId derived from the ControlNumber to stop a duplicate send on a re-read. Inbound Twilio status callbacks are validated against the X-Twilio-Signature header using HMAC-SHA1 with your Auth Token before they are trusted.