Microsoft Dynamics 365 Business Central and Twilio integration

What moves between them

The flow runs one direction, from Microsoft Dynamics 365 Business Central into Twilio. ml-connector reads Business Central financial events and turns them into outbound Twilio messages: an overdue or due-soon notice when a sales invoice changes state, an approval alert when a purchase invoice posts, a receipt confirmation when a customer payment is recorded, and a credit-limit warning when a customer balance crosses its limit. A one-time passcode through Twilio Verify can gate a sensitive change such as updated bank or remit-to details before it is written back to Business Central. Delivery and call status flows back from Twilio into the audit record so a failed or undelivered send is visible. Twilio holds no accounting data, so no financial records are written back into Business Central.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Business Central it runs the OAuth 2.0 client credentials grant against Microsoft Entra ID, caches the bearer token, and builds the base URL from the stored environment name. For Twilio it sends API Key Basic Auth on every request and uses form-encoded bodies, since Twilio rejects JSON request payloads. It registers Business Central subscriptions on entities like salesInvoices, purchaseInvoices, customers, and customerPaymentJournals, answers the validationToken handshake, and renews each subscription before the three-day expiry through a cron job. Because the BC notification carries no data, the connector fetches the changed record by id, maps it to a message template and a destination phone number, and sends through Twilio. Numbers are normalized to E.164 first, because a missing plus prefix fails quietly. Purchase orders are polled with a lastModifiedDateTime filter since they have no webhook. On a Twilio 429 the connector backs off with jitter, and each send carries a stable jobId so a retry does not double-send. Inbound Twilio status callbacks are verified against the X-Twilio-Signature header before the audit record is updated.

A real-world example

A mid-sized regional distributor with about 120 staff runs Microsoft Dynamics 365 Business Central for purchasing, sales, and accounts receivable. Collections was slow and manual: a clerk pulled an aged receivables list each morning and called or emailed overdue accounts one by one, and finance approvers often missed large AP invoices sitting in review until vendors chased payment. With Business Central and Twilio connected, a sales invoice that goes overdue triggers an SMS reminder to the customer contact automatically, a posted purchase invoice over a set amount pings the approver by text, and a one-time passcode confirms any change to vendor bank details before it is saved. The morning call list shrinks, approvals move the same day, and every message is logged against the source record.

What you can do

• •Send Twilio SMS reminders to customers when a Business Central sales invoice goes overdue or comes due soon.
• •Alert approvers by text when a purchase invoice posts in Business Central above a configured amount.
• •Confirm a recorded customer payment with an outbound Twilio message tied to the payment journal entry.
• •Gate sensitive vendor or customer changes with a Twilio Verify one-time passcode before writing back to Business Central.
• •Renew the three-day Business Central webhook subscriptions on schedule and retry throttled Twilio sends with a stable job id.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Twilio?

It moves one direction, from Business Central into Twilio. Invoice, payment, and customer events in Business Central trigger outbound SMS, voice, or passcode messages through Twilio. Twilio has no vendor, invoice, or GL records, so no financial data is written back into Business Central; only delivery status returns for the audit trail.

Can Twilio store invoices or other accounting records from Business Central?

No. Twilio is a communications platform with messages, calls, phone numbers, and passcode checks, and it has no invoice, purchase order, vendor, or GL objects. ml-connector uses Business Central as the system of record and turns its financial events into Twilio notifications and verification messages rather than syncing accounting data into Twilio.

How does the integration handle Business Central webhooks and Twilio retries?

Business Central subscriptions expire after three days, so ml-connector answers the validationToken handshake and renews each one on a schedule before it lapses. Because the notification carries no payload, the connector fetches the changed record before sending. Twilio does not guarantee exactly-once delivery, so each send uses a stable job id and backs off on a 429 to avoid double-sending.