Record a WhatsApp opt-out once in an authoritative suppression record, then propagate it to both the CRM and the messaging platform. Keep evidence of the request, distinguish channel-wide restrictions from purpose-specific preferences, and verify the restriction at every sending route. A CRM checkbox alone is not enough if campaigns, agents or queued messages can still reach the person.
The workflow below is a proposed design for a South African business. It requires technical evaluation and qualified human judgement on privacy, legal scope, retention and security. It is not a claim that any named platform provides the complete process natively.
1. Decide what the request stops
Apply the restriction the person requested, without silently narrowing it to marketing or extending it to unrelated channels.
The Source: WhatsApp Business Messaging Policy, last updated on 23 September 2026, requires businesses to respect requests made on or off WhatsApp to stop WhatsApp communications, including removing the person from their contacts list. A request received by email or a call-centre agent therefore needs an intake route too.
Proposed scope rules should distinguish:
- WhatsApp-wide stop: “Do not contact me on WhatsApp again.”
- Purpose-specific stop: “Stop sending me WhatsApp specials.”
- Broader objection: “Stop all your marketing.”
- Unclear request: “Enough now.”
Do not treat a broad WhatsApp stop as permission to send messages labelled “service”. For an unclear request, place a protective hold on affected outbound activity while a person reviews context. Avoid making clarification messages a compulsory step before suppression.
The Information Regulator’s Source: guidance notes include direct-marketing guidance dated 3 December 2024 covering sections 11 and 69 of POPIA. Ask a qualified adviser to review the proposed scope rules rather than treating platform policy as the complete legal answer.
2. Choose one authoritative suppression record
Make one record authoritative and let other systems hold synchronised copies or references.
The record can live in the CRM or a separate preference store. Choose according to which component can reliably control all sending routes, not which screen is easiest to edit. If the CRM is authoritative, the messaging platform still needs an enforceable local restriction when the CRM is unavailable.
Use this proposed minimum data dictionary:
| Field | Purpose |
|---|---|
| Suppression record ID | Stable reference shared by connected systems |
| Business or account scope | Identifies which organisation’s communications are restricted |
| Channel identifier | Normalised number or supported platform identifier |
| Linked CRM IDs | Connects known duplicate contact records |
| Channel and purpose scope | Separates WhatsApp-wide restrictions from narrower preferences |
| Status and effective time | Records when the restriction began |
| Source event ID and evidence reference | Links to the request without copying an entire conversation |
| Version and actor | Supports ordered changes and accountability |
| Per-system sync state | Shows pending, confirmed or failed updates |
| Review owner | Assigns unresolved identity or scope questions |
Restrict access to this record. Agree evidence retention and identifier protection with privacy and security owners. The AI CRM integration glossary explains the connection concept, but the suppression rules remain an explicit design responsibility.
3. Capture the request without waiting for a perfect CRM match
Save the inbound event and apply an identifier-level hold before resolving missing or duplicate contact records.
The proposed intake sequence is: receive the request, record its source identifier and receipt time, check whether the event has already been processed, apply the protective restriction, and then link CRM records. A missing CRM contact must not turn into permission to keep sending.
Use a source event ID as a deduplication key where available. For manually recorded requests, create a unique intake reference and record the staff member who entered it. Reprocessing the same event should not create contradictory preferences or release an existing restriction.
For telephone numbers, use a reviewed normalisation procedure. Do not assume that every local-format number belongs to South Africa or that similar numbers identify the same person. Flag uncertain country codes, shared numbers and identifier changes for review.
Simple, explicit requests can use deterministic rules. AI may help suggest the scope of free-text requests, but should not invent consent or resolve identity conflicts. The WhatsApp AI agents resource provides broader workflow context; this intake should remain narrowly focused on capturing and enforcing preferences.
4. Propagate the restriction and verify the result
Write the restriction to each affected system, then read back the stored state rather than treating an attempted update as success.
A proposed propagation job should carry the suppression record ID, current version, affected identifier, scope and effective time. Update CRM preference fields, messaging-platform restrictions and campaign audience controls as separate destinations. Include agent interfaces and external sending tools in the destination inventory.
Record each destination independently. “CRM confirmed, platform failed” is a partial failure, not a completed opt-out. Retain the local sending hold, retry safely and assign the failure to an operations owner. Use provider-supported controls where available; otherwise evaluate whether your own sending gateway can enforce the restriction. Do not assume a particular subscription or provider has the necessary API.
Make retries safe to repeat. An older update arriving late must not overwrite a newer restriction or an authorised preference change. Version checks are a proposed way to handle this.
Removing a person from a sendable contact list and retaining a minimal suppression record serve different purposes. Have the privacy owner review how to honour removal requirements while keeping only the information needed to avoid recontacting the person.
5. Check suppression at the point of sending
Check the current restriction immediately before dispatch, not only when building the campaign audience.
A proposed sending gate should compare the destination identifier, business scope, channel and purpose with the authoritative restriction. If the record is unavailable or its status is unresolved, hold affected outbound sends and alert an owner rather than assuming permission.
Cover scheduled campaigns, automated follow-ups, agent-written replies, bulk imports and retries. A message selected before the opt-out may still be sitting in a queue. Cancel it where the integration permits cancellation, or ensure the dispatch gate rejects it. If it has already been handed to the provider, record that limitation and investigate the timestamps; do not promise recall.
Template approval and a service window are not substitutes for preference checks. Classifying a message as operational also does not automatically justify an exception to a channel-wide stop. A qualified reviewer must decide any permitted handling and suitable alternative channel.
This is a focused CRM automation integration task: the acceptance question is whether all actual sending routes consult the restriction, not whether two screens display matching labels.
6. Give exceptions a human owner
Route uncertain scope, conflicting identity and proposed re-subscription to people with defined authority.
Use a review queue containing the evidence reference, current restriction, affected destinations and the specific decision required. Keep the hold in place while the decision is pending. A reviewer should not need to inspect unrelated conversations to understand the case.
Proposed review categories include:
- A shared number linked to several customers.
- A request that could mean one campaign or all WhatsApp messages.
- A CRM merge involving different preferences.
- A later request that appears to restore permission.
- A service team asking to contact someone despite a broad stop.
The Source: n8n human-review documentation describes pausing selected AI tool actions for approval or denial. That supports a possible review mechanism, not a complete suppression solution. If used, confirm that the selected version and deployment support the required integration.
Do not delay an explicit stop while waiting for approval. Reserve review for uncertain interpretation and consequential changes. The customer-service agents resource is relevant to handover design, especially where an agent needs to explain a restriction without overriding it.
7. Reconcile records and evaluate failures
Compare actual stored restrictions and send behaviour, not just successful workflow logs.
Propose a reconciliation schedule based on sending frequency and operational risk. Compare the authoritative record with CRM fields, platform restrictions, queued audiences and duplicate identifiers. An import should preserve existing restrictions even when the imported contact contains an older “subscribed” value.
Track unresolved updates, mismatched versions, sends attempted after the effective time, reviewer decisions and accidental reactivations. These measures can show whether the design works under evaluation; they do not prove legal compliance or guarantee fewer errors.
For each mismatch, identify whether the cause was intake, identity matching, propagation, queue handling or a bypassed send route. Assign corrective work and repeat the relevant test. A connector restart should not require manually reconstructing which requests were processed.
Agree incident handling before use. If a restricted message is sent, preserve the evidence, contain further sends and involve the appropriate privacy and operational owners. Decide any notification or remedy through qualified human judgement.
Broader AI automation may coordinate these steps, but deterministic restrictions and accountable review should control the final action.
Suppression-sync acceptance checklist
Use this proposed checklist for each sending route. Mark an item complete only when a controlled test provides evidence, not because a configuration screen looks correct.
- Name the authoritative record, operational owner and privacy reviewer.
- Document WhatsApp-wide, purpose-specific and broader marketing scope rules.
- Record identifier, effective time, source event, evidence reference and version.
- Capture requests received through WhatsApp, email, calls and staff entry.
- Apply a protective identifier-level hold when CRM matching is unresolved.
- Repeat the same intake event without creating conflicting records.
- Update every linked CRM contact and relevant messaging restriction.
- Read back destination states and retain evidence of confirmation.
- Keep affected sends blocked during partial failures and safe retries.
- Reject stale updates that could overwrite a newer restriction.
- Test queued campaigns, manual agent sends and automated follow-ups.
- Verify imports and contact merges cannot silently restore permission.
- Assign ambiguous scope, shared identifiers and reversals to human review.
- Confirm contact-list removal, minimal retention and access controls with responsible reviewers.
- Reconcile mismatches and document provider cancellation limitations.
- Obtain operational acceptance and qualified privacy review of unresolved exceptions.
Completion rule: retain test evidence for every applicable item, name owners for exceptions, and do not accept a route that can bypass the restriction.
Worked walkthrough: clear, missing and duplicate cases
Treat unresolved identity as a review problem, not a reason to ignore the request.
In this hypothetical example, a customer sends “Stop all WhatsApp messages” at 09:10. One CRM contact matches the source identifier. The proposed workflow saves the event, applies a WhatsApp-wide restriction and updates both destinations. At 09:11, read-back confirms matching versions. A campaign message queued earlier is rejected at dispatch. These fictional times illustrate sequence, not a promised processing speed.
A second hypothetical request comes from an identifier with no CRM match. The workflow keeps an identifier-level suppression record and blocks affected sends. A staff member investigates whether it belongs to an existing contact. The team does not create a marketing-ready lead merely to store the request.
In a third hypothetical case, two CRM contacts share the identifier and the message says “No more specials”. The proposed rule holds WhatsApp marketing for that identifier and links both possible records for review. A person examines context without automatically merging the contacts or stopping unrelated email preferences. If the scope remains uncertain, the protective hold remains.
Finally, a delayed import marks one duplicate as subscribed. Its older value cannot clear the restriction. A reviewer records the conflict and asks the integration owner to correct the import behaviour before acceptance.
FAQs
Keep the same suppression authority when answering exceptions; do not create a separate informal rule for each team.
Should an opt-out received by email stop WhatsApp messages?
Yes, when the person is asking to stop WhatsApp communications. Capture the email as the source event and identify the relevant WhatsApp destination through a reviewed process. If the identifier is uncertain, escalate matching without requiring the person to repeat the request on WhatsApp. Do not automatically suppress unrelated channels unless the wording supports that broader scope.
What if the CRM updates but the messaging platform fails?
Treat the request as effective and the propagation as incomplete. Keep affected sends blocked through a working enforcement point, retry the platform update safely and alert the named owner. If no reliable gate can block that route, suspend the affected outbound activity while the owner resolves it. Read back the platform state before marking the destination confirmed.
Can a later customer message clear the opt-out?
Not by itself. A new support question is not necessarily permission to resume campaigns or general WhatsApp contact. Preserve the restriction and have a person assess any explicit request to change it, including its scope and supporting evidence. Record an authorised change as a new version rather than deleting the original event. Do not let an AI confidence score authorise re-subscription.
If your business needs help connecting these preference records, get in touch to discuss the sending routes, exception ownership and acceptance evidence before choosing the automation design.