What it does

Connects WhatsApp to Copilot Service admin center through Twilio, so reps pick up and answer WhatsApp conversations in Copilot Service workspace. This is the supported route for new WhatsApp deployments now the Azure Communication Services version is on a removal clock.

Key facts

• You need a Twilio account and, for each WhatsApp number, an Account SID, Auth token and the number itself. Copilot Service admin center then generates a Twilio inbound URL on the Callback information page, which you paste back into Twilio as the incoming message webhook.
• Sandbox versus production. The Twilio sandbox uses a shared number, only supports phones that have sent join <code>, expires each phone's connection after three days, and is limited to one message every three seconds. Custom message templates aren't supported in the sandbox. The sandbox only exists in the legacy Twilio Console; trial accounts on the current console get a "Try out WhatsApp" experience instead.
• 24-hour session rule. A session opens when the customer messages you and runs 24 hours from their latest message. Inside it reps reply freely; outside it they can only send a WhatsApp-approved template until the customer answers.
• Templates are built in the Twilio Content Template Builder (the old WhatsApp Template Console tab and Templates API are deprecated). Dynamics identifies each one by its Content template SID, not its name, and you paste the approved text in exactly. One content template covers one language, so a multilingual rollout means one template and one WhatsApp approval per language.
• Newly created Twilio accounts block media sending by default; you have to switch that security setting off before attachments will flow.
• You need permissions on secure columns, and channels must already be provisioned in the environment.
• Business-Scoped User IDs. When a customer adopts a WhatsApp username, the phone number is no longer sent and a BSUID (two-letter country code, a dot, up to 128 alphanumerics, e.g. US.13491208655302741918) becomes the primary identifier.

When to use / skip

Use it for any new WhatsApp deployment, and as the destination for existing ACS-based WhatsApp channels. Skip it only where WhatsApp genuinely isn't a customer channel in the client's markets; it matters most across LATAM, MENA, South Asia and Southeast Asia and far less for North American B2B.

Configuration decisions

• Sandbox first, or straight to production. Sandbox is worth a day for proving routing and workstream behaviour, but it can't prove templates, so production testing is unavoidable.
• Which templates to create, in which languages, and who owns WhatsApp approval on the client side.
• Whether to keep the WhatsApp Contact Book on. It's on by default; switching it off permanently loses phone number as an identifier for customers who adopt usernames.
• Routing rules: any condition on phone number patterns (country-code routing, say) won't match a conversation that only carries a BSUID, so add a fallback rule.
• File attachments: the workstream's User features page controls whether customers, reps or both can send them.
• Which of your flows, integrations and AI agent context variables rely on msdyn_CustomerPhoneNumber and need a BSUID path.

Gotchas

• Pasting the inbound URL in the wrong place is the commonest sandbox failure. Sandbox: "When a Message Comes in" under sandbox configuration. Production: the WhatsApp sender's incoming message webhook.
• Sandbox testing hides the template problem. Everything works freely, then in production the first conversation older than a day needs an approved template and the rep is stuck.
• Template identification by SID rather than name catches people copying from the wrong Twilio screen. A mismatched approved text won't error cleanly.
• If the Contact Book is switched off, the phone number can't be recovered later. Treat it as a one-way door.
• Where a customer has no phone number, reps see the first and last name only if the conversation is linked to a contact. Otherwise it displays as Visitor.
• Power Automate flows and AI agent logic keyed on the customer's phone number will quietly stop matching once customers adopt usernames.

Consultant notes

• Put template approval on the plan as a named dependency with a client owner. It's outside your control, it's per language, and it's the thing that slips go-live.
• Test with a phone that hasn't messaged in 24 hours before UAT sign-off. If you only ever test inside a live session you haven't tested templates at all.
• Run a BSUID audit during design rather than after go-live: routing rules, flows, reporting that groups by phone number, and agent context variables. Retrofitting a fallback route under pressure is miserable.
• For clients migrating off ACS, don't assume templates and consent carry across; budget for fresh approvals and a short parallel-run period.

---

Worth another look as WhatsApp's username rollout timeline firms up, and when the ACS migration tooling is published.