Dynamics 365 Customer Insights Journeys: SMS and Custom Channel Deduplication Planned for December 2026

The roadmap record lists the feature as In development, with general availability targeted for December 2026 on the web platform in Worldwide (Standard Multi-Tenant) environments. That is a planned release, not confirmation that administrators can enable it now. Microsoft explicitly warns that roadmap descriptions and dates are estimates and can change.

The destination, not just the customer record​

The important distinction is contact-point deduplication. The planned capability addresses repeated destinations, rather than merely repeated contact records.

Consider a hypothetical campaign containing three contacts that share one mobile number. Under the behavior described in the roadmap, that number would receive one copy during the send. The same principle would apply when multiple recipients share a custom-channel address.

Microsoft positions the change as a way to reduce unnecessary messaging expenditure, duplicate-message annoyance and manual cleanup. Those are intended benefits, not measured results: the record provides no savings figures or delivery benchmarks.

There is also a boundary worth preserving. “Once per send” does not mean “once across every campaign.” The available description does not define whether a send corresponds to a message tile, journey execution or another processing boundary. Organizations should not treat it as a blanket frequency cap.

Email offers a useful—but limited—comparison​

Microsoft Learn documents an existing email-deduplication capability. When enabled, it checks segment contacts’ addresses as they reach an email tile and sends one email per unique address. Additional contacts sharing that address appear as blocked under Duplicate recipient address in Delivery and interaction details. Microsoft documents email deduplication as disabled by default.

For administrators reviewing that existing email feature, the documented controls are:

1. Open Settings > Feature switches.
2. Find the Email sending section.
3. Enable Email deduplication.
4. Inspect the journey or email’s Delivery and interaction details, looking under blocked results for Duplicate recipient address.

Those are email controls—not instructions for enabling the planned SMS and custom-channel feature.

Email also demonstrates why scope matters. Microsoft says its deduplication works at the email level within a journey; it does not prevent repeat delivery across separate journeys or across different email tiles within the same journey. These documented limits provide a useful comparison, but they do not establish the rules for the forthcoming channels.

Deduplication is not consent management​

Customer Insights – Journeys already uses contact-point-based consent. Microsoft’s documentation explains that consent is associated with an address or phone number rather than solely with a contact record. It also states that, by default, recipients must opt in to receive commercial SMS and commercial custom-channel messages.

The operational distinction is straightforward: consent determines whether a destination is eligible for a message; deduplication concerns repeated copies reaching that destination. Administrators should evaluate these as separate controls, not assume that preventing duplicates makes a recipient contactable.

What administrators should validate at release​

The roadmap supplies a concrete objective, but not enough implementation detail for a supported setup procedure. Before changing production journeys, administrators should establish:

• Activation: Is deduplication automatic, or does it require a setting?
• Matching: How are differently formatted phone numbers and custom addresses compared?
• Scope: What exactly constitutes one send?
• Personalization: Which contact supplies the content when records share a destination?
• Reporting: How are suppressed recipients recorded, and do they continue through the journey?
• Compatibility: Are there provider-specific or custom-channel requirements?

A sensible acceptance test, once Microsoft confirms availability, would use controlled records sharing a test destination and compare actual deliveries with journey reporting. That is a proposed validation approach, not a claim about released functionality.

The attraction here is refreshingly practical: fewer repeated messages, rather than another dashboard explaining why they happened. For now, however, December 2026 remains a target. Keep existing safeguards in place until availability and operating boundaries are confirmed; Microsoft’s roadmap is a planning signal, not a deployment receipt.