Duplicate messages stop when every outbound action must earn permission from one shared send authority record. Check the customer identity, message purpose, current journey state, channel permission, recent replies and completed outcomes immediately before sending. Then claim a stable collision key so another journey, branch or retry cannot send the same purpose again.
This is broader than removing duplicate rows from a campaign list. A customer can be unique inside an email journey and still receive the same reminder from a service workflow, a WhatsApp campaign and a manual agent. The control must sit above individual campaigns and channels.
Why duplicate messages escape ordinary deduplication
Most duplicate controls answer a narrow question such as whether one address appears twice in one audience. Microsoft documents an email deduplication feature that works at the email tile and per journey. It does not detect the same email across separate journeys or different tiles in the same journey. That distinction matters because the customer experiences the business as one sender, not as a set of independent workflow IDs. Microsoft explains the per journey boundary here.
Duplicates also appear without a duplicate contact row. Two branches may rejoin before an action. A webhook can be retried. An operator can send while an automation is waiting. A customer can qualify for a campaign and a service reminder at the same time. Bloomreach documents how independently processed branches can reach one action more than once, while Community documents repeated attempts from flows, integrations, manual sends and API replays.
Treat these as authority failures. More than one process believed it was allowed to act for the same customer purpose.
Build one send authority record
Create a small record for every customer outcome that can produce outbound messages. It does not need to contain message content. It needs enough state to decide whether a send is still allowed.
Use these fields:
- Canonical customer ID that links the verified channel identities
- Purpose such as order ready, appointment reminder or quotation follow-up
- Journey instance and business object such as order 4821
- Current outcome state such as pending, completed, cancelled or disputed
- Eligible channels and the evidence for permission on each contact point
- Active conversation and human owner if one exists
- Last planned action, claimed collision key and final delivery result
- Expiry time and recovery owner for an uncertain attempt
The purpose and business object are essential. A delivery update and a marketing offer may be sent to the same person on the same day without being duplicates. Two order-ready messages for the same order probably are duplicates even when the copy and channel differ.
Check six conditions before every send
Run the check as late as possible, after a delay ends and immediately before the provider call. A customer can reply, opt out or complete the task while a message is waiting.
- Identity check. Do all channel identities resolve to the same verified customer and business object
- Purpose check. Has this purpose already been sent, completed, cancelled or superseded
- Permission check. Is this contact point eligible for this purpose now
- Conversation check. Is a customer or employee actively handling the matter
- Priority check. Is another journey the declared owner of the next action
- Collision check. Has another process already claimed the same customer, purpose and outcome window
Consent is not one universal boolean. Microsoft describes contact-point consent for email addresses and phone numbers. WhatsApp separately requires the number and opt-in permission, requires opt-out requests to be respected, and restricts business-initiated messages to approved templates. Review the current WhatsApp Business Messaging Policy and the laws that apply to your audience.
A failed condition should produce a visible reason such as suppressed after reply, permission missing or outcome complete. Silent skips are hard to audit and easy to work around.
Use one key for retries and branches
Create a collision key from stable business values rather than message copy. One useful pattern is customer ID, purpose, business object, outcome version and time window. For example, a pickup reminder for order 4821 can have one key whether the approved channel is WhatsApp or an external SMS sender.
Claim the key before calling the channel provider. Store three states. Claimed means one process owns the right to attempt. Sent means the provider accepted the request. Uncertain means the result is unknown and needs reconciliation before another send.
Do not release the key immediately after a timeout. The provider may have accepted the message even when your system missed the response. Put the attempt in a recovery queue, check the provider result or delivery event, and let one owner decide whether a retry is safe. A retry must reuse the original key.
This design also controls merged branches. Each branch can evaluate customer state, but only one can claim the outbound action.
Stop every journey when the customer acts
A customer reply is new state, not another signal to store for later. It should pause competing follow-up, attach the conversation to one owner and prevent scheduled reminders from talking over the person. A purchase, booking, cancellation, opt-out or resolved case should do the same for the relevant purpose.
Microsoft documents journey exits based on events or suppression segments. That is useful, but the stop event must reach every journey that can act on the same purpose. It also arrives too late to recall a message that has already been sent. The final send check therefore remains necessary.
Define the stop matrix before launch. For each customer event, list which purposes end, which continue and who owns any exception. An order completion may stop cart recovery but not a safety notice. A reply to a quotation may stop automated follow-up and assign the salesperson.
Choose channel roles before building the flow
Do not make every channel a fallback for every other channel. Give each channel a job. Email may carry a detailed document. WhatsApp may support a live conversational step when the customer has opted in. SMS may be reserved in an external system for a permitted urgent fallback. These are examples, not automatic rules. Customer preference, permission, urgency, cost and content should decide.
Write one channel policy for each purpose:
- Preferred channel and why it suits the task
- Allowed fallback and the condition that unlocks it
- Minimum wait before a fallback
- Reply or outcome that cancels all remaining actions
- Owner when delivery is uncertain
If several products execute the channels, keep one system responsible for journey state. External senders should receive a specific action and report the result. They should not independently decide the next customer step.
Test the florist order journey
A florist accepts a custom order for collection on Friday. The customer agreed to operational WhatsApp updates and also provided an email address for the receipt. The business wants to send one ready-for-pickup notice.
At 15:00, the order system changes the order to ready. The send authority record checks the customer, order, purpose, WhatsApp permission, current conversation and outcome. It claims the key for order-ready version three and sends the approved WhatsApp message. The email receipt remains a different purpose and is unaffected.
At 15:04, an integration retries the ready event. It reaches the same key and is suppressed. At 15:10, the customer replies that a colleague will collect the bouquet. The reply pauses the reminder journey and assigns the conversation. At 16:00, a separate campaign branch reaches a generic pickup reminder. The outcome and active conversation checks block it.
If the first provider result had been uncertain, the system would place it in recovery rather than immediately switching to another channel. That prevents one temporary timeout from becoming two customer messages.
Measure prevented collisions and recovery
Delivery rate cannot show whether journey control is working. Add measures that expose competing authority and operational recovery.
Track attempted actions, approved sends, suppressed duplicates, suppression reason, uncertain attempts, time to reconcile, manual overrides and messages sent after a reply or completed outcome. Review them by purpose and source journey.
A rising suppression count is not automatically success. It may show the gate works, or it may reveal unnecessary overlapping journeys. Remove redundant triggers and branches rather than celebrating every blocked attempt. Review a sample of allowed and suppressed records each week until the reasons are stable and understood.
The strongest outcome measure is simple. The customer received the right message once, and the team could explain why it was sent.
How DripTell fits the operating model
DripTell journey automation can start from customer or external events, evaluate conditions, wait, switch a supported channel, call another system and assign the conversation. Workflows can pause, end or change state after a customer or teammate replies. The DripTell Team Inbox keeps customer context, channel, owner and next action together.
Use those controls to hold the journey state and human ownership for connected messaging work. When another system sends a channel, pass it an explicit action through an approved integration and bring the result back before authorizing the next step. Verify current channel availability and technical contracts in the developer documentation.
DripTell is not a substitute for consent policy, legal review or provider rules. The practical value is making conditions, ownership, external calls and reply-based stops visible in one operating flow.
A practical launch checklist
Start with one purpose that has a real duplicate risk. Map every campaign, automation, integration and manual team that can send it. Choose the canonical customer key and business object. Define the outcome states and contact-point permission evidence. Create the collision key and uncertain recovery state. Add reply, completion, cancellation and opt-out stops.
Test these cases before launch:
- The same event arrives twice
- Two branches reach the action together
- A second journey claims the same purpose
- The customer replies during a delay
- An employee starts a live conversation
- Permission changes before the send
- The provider times out after accepting the request
- The business outcome completes in another system
Release to a small audience and inspect every suppression and recovery. Once one purpose is reliable, reuse the control model for the next journey. If your team needs to map the authority gate across messaging, inbox ownership and external systems, book a DripTell walkthrough with one real workflow ready to test.
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