Want help applying this guide?Ask the DripTell team
A customer may not know that the messaging path behind a familiar support button is about to change. They only know that they sent a question about an order, appointment, or payment and expect the business to remember it. That is the standard for this cutover.
Microsoft deprecated its Apple Messages for Business channel in Dynamics 365 on July 17, 2026, and says it will remove the channel from Copilot Service admin center on September 30, 2026. If your team uses that specific Dynamics 365 connection, treat this as a customer continuity project. Do not simply delete a channel and add another one.
Map every entry point, preserve open work and ownership, choose a supported replacement, test it as a customer, and monitor both paths. The notice is about Microsoft's Dynamics 365 channel configuration. It does not say that Apple Messages for Business itself is ending everywhere.
What Microsoft is actually removing
Microsoft's deprecation notice is narrow but urgent. The Apple Messages for Business channel was deprecated on July 17, and its Copilot Service admin configuration is scheduled for removal on September 30. Microsoft says alternative channel integration options are available and directs teams to support for help.
- Scope the noticeSeparate the Dynamics 365 channel removal from the wider Apple service.
- Map every entranceFind each public button, link, campaign, document, and saved instruction.
- Protect open workKeep the customer, owner, status, promise, evidence, and next action together.
- Prove the replacementTest discovery, routing, context, response, completion, and failure handling.
- Monitor the changeWatch volume, unassigned work, response, transfers, failures, and confusion.
Do not assume nothing changes because Apple Messages still exists outside Dynamics 365, or tell customers that Apple is closing the entire service. Neither follows the notice. Your scope is the connection, routing, customer history, and operating rules attached to the Microsoft channel.
The current Microsoft channel configuration guide shows why a simple endpoint swap is risky. The setup can include workstreams, routing, automated messages, authentication, attachments, Apple Pay, surveys, notifications, context variables, quick replies, rich messages, and optional AI handling. Your business may use only some of these, but each active dependency needs an explicit destination or retirement decision.
| Area to inspect | Evidence to capture | Cutover decision |
|---|---|---|
| Customer entry points | Every live button, app link, website path, and campaign source | Replace, redirect, or retire |
| Open conversations | Customer, current owner, status, last promise, and next action | Continue with the same accountable owner |
| Channel behavior | Routing, automation, authentication, files, payments, and surveys | Rebuild, simplify, or stop deliberately |
| Reporting | Volume, response, resolution, failures, and unresolved work | Preserve the baseline and define the new view |
Start with the customer entry points
Do not begin inside the admin screen. Begin where customers actually find the channel.
List every website button, mobile app link, Maps or search entry, email signature, campaign, QR placement, printed instruction, and saved help article that can start an Apple Messages conversation. Add the business owner and last verified date for each one. A forgotten link is not a small documentation error after cutover. It is a customer doorway that may stop leading to a staffed team.
Compare that list with actual traffic. A quiet link may still serve accessibility, payment, or appointment help, so decide with evidence. Use the shared inbox overview to define the channels and queues operated after the move.
Write a plain customer promise: where to continue, when to expect a reply, and what to do with an urgent open request. Do not promise automatic history transfer unless you have tested it.
Preserve active work before changing the route
An open conversation is not just a transcript. It has an owner, a current state, a last commitment, and often a deadline. Export or record those elements before you alter the connection.
Start with unresolved conversations. Retain the permitted customer identifier, assigned owner, status, last meaningful message, necessary attachments, relevant consent or authentication state, and next promised action. Keep only data your policy allows.
Put one named person in charge of each carried case. The conversation assignment guide can help teams separate queue ownership from individual ownership. Preserve the meaning of open, pending, and resolved states using the conversation status guide rather than flattening every imported item into a generic open bucket.
If old messages cannot be imported, give agents a concise case note: why the customer contacted you, what happened, what is still owed, and where the evidence lives.
Test the replacement as a real customer would
Choose the replacement for the customer's task, not just the channel name. Confirm availability, consent, security, message features, payments, and cost with the provider you choose.
Build one controlled test for every material journey. Start from the real public entry point. Send a normal question, an attachment if supported, and an authentication request if the journey needs one. Verify that the conversation reaches the correct queue, keeps the expected customer context, shows one clear owner, pauses inappropriate automation, and can be resolved without asking the customer to repeat the whole story.
Test the failure path too. What happens outside business hours or when no routing rule matches? Can a supervisor find an unassigned conversation? The routing rules guide explains the controls worth checking. Readiness means the full customer task works, not that one message arrived.
Run the cutover with named owners
Use a short change window with a written go or no go decision. Name owners for entry points, open conversations, routing, automation, and customer communications. A small team can combine roles.
Remove or replace old entry points only after the new path passes. Keep a list of every changed location so nothing is left behind. During the first operating period, watch new volume, unassigned work, first meaningful response, transfer rate, failures, and customer reports that the path is confusing. Compare them with the preserved baseline in your inbox reports.
If a critical journey fails, stop promoting the new route and use the documented fallback. Record the failure, owner, customer impact, temporary route, and retest result.
A clean cutover ends with proof. Archive the notice, dependency inventory, open-case handover, tests, entry-point changes, and closure decision. If systems must exchange customer state, review integration options without assuming a connector transfers every permission or historical detail.
Frequently Asked Questions
Is Apple Messages for Business shutting down everywhere
No. Microsoft's notice says its Apple Messages for Business channel in Dynamics 365 is deprecated and will be removed from Copilot Service admin center on September 30, 2026. It does not announce the global end of Apple's service.
What should be moved first
Move accountability before archives. Identify every unresolved customer conversation, preserve its owner, status, last promise, evidence, and next action, then decide how the customer will continue.
Should we delete the old channel on September 30
Do not make deletion the first step. Confirm the exact behavior in your tenant with Microsoft, pass the replacement tests, update public entry points, preserve required evidence, and keep a controlled fallback.
How do we know the replacement is ready
It is ready when a real customer can discover it, start the intended task, reach the correct team, retain enough context, receive a meaningful response, and complete the journey while failures remain visible to an owner.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy