Data, privacy and consent

DMLY has four separate switches that people routinely confuse: opt-out, blocked, bot paused, and deleting the contact outright. They stop different things. Getting them mixed up is how a business keeps messaging someone who told it to stop. Read this first, because it is the one people get wrong: Prefer to watch first? This walkthrough covers opt-outs, blocking and deleting a contact.

​

The four switches

Opt-out and blocked are the two that count as suppression. Both appear on Contacts → Suppressions.

​

How a contact opts out

A contact opts out by sending one of these words as their whole message: stop · stopall · stop all · unsubscribe · cancel · quit · end · opt out · optout The match is exact. “cancel my appointment tomorrow” does not opt anyone out, because the message is not only the word cancel. But a contact who replies with just cancel (meaning their booking, not your marketing) is opted out immediately and silently. The list is the same on every channel. Telegram also accepts its /stop command on top of it. To opt back in, the contact sends start, unstop, subscribe, opt in or optin. On Telegram, /start works as well. These are only honoured while the contact is already opted out; a contact who has never opted out cannot “double opt in” by typing subscribe. You can also clear it yourself with Resubscribe on Contacts → Suppressions. Only do that when you have a record of the contact asking.

​

What opting out actually stops

At the moment a contact opts out, DMLY immediately:

• cancels any Flow they are currently running
• stops any Sequence they are enrolled in

From then on, automated messages do not reach them:

• Broadcasts: opted-out contacts are still counted into the audience unless you tick Reachable contacts only; the send itself is refused at the channel sender, so they land in the broadcast’s failed count rather than receiving the message
• Sequences: due steps skip them
• Automations: the send step refuses, and any “can I reach this contact?” check returns no
• Booking reminders: appointment reminders are not sent

DMLY also writes a system message into the conversation so your team can see what happened: “Contact opted out (STOP) — automated messages suppressed. Agents can still reply manually.” Ignore the last sentence of that message. It is out of date: a manual reply is refused, as the next section explains.

​

Manual replies are refused too

An agent who replies by hand to an opted-out contact gets an error instead of a sent message: “This contact opted out of messages — resubscribe them before replying.” The mobile app and the MCP send tools get the same words. The public API refuses with the same message ending “before sending.” The check runs on the server, so it covers every one of those, and a payment link sent from the Inbox is refused too. That includes a contact who unsubscribed from your offers but is still mid-conversation about an order. To carry on, the contact must opt back in by sending start, or someone must Resubscribe them on Contacts → Suppressions. Only resubscribe someone when you have a record of them asking.

​

The Unsubscribe tag

Every workspace ships with one tag called Unsubscribe, and DMLY keeps it in step with opt-out automatically: it is attached when someone opts out and removed when they opt back in, on every channel, Telegram included. That tag is why you cannot rename or delete it. The UI says so directly: “This tag is required for opt-out compliance and can’t be renamed.” Its practical use is in Segments. Add Unsubscribe to Exclude contacts with tags and the segment drops those people by tag as well as by timestamp: belt and braces on any audience you reuse. See Tags and segments.

​

Blocking

Blocking is a different axis from opt-out and is done from the conversation in the Inbox, not from the contact’s page. It sets the contact’s status to blocked and pauses their bot in one move, and automations treat a blocked contact as unreachable. Like opt-out, blocking stops manual replies, and it makes that plainer. The composer is hidden, and a request that gets sent anyway is refused by the server; the same goes for payment links. The conversation shows the contact is blocked, with the note ”— replies are disabled. Unblock from the details panel to message again.” The difference is who decides and what else it does. Opt-out is the contact’s own request. Blocking is your decision, and it also pauses the bot. Both are reversible. Use blocking for spam, abuse and time-wasters. Use opt-out for consent. A contact can be both, and the Suppressions list shows both.

​

The Suppressions list

Contacts → Suppressions is a filtered view of “Blocked and unsubscribed contacts — no automated messages are sent to them.” Filter it by Blocked or Unsubscribed. Each row gives you the action that matches its axis:

• Unblock: clears the blocked status
• Resubscribe: clears the opt-out and removes the Unsubscribe tag

Two switches, two buttons. Unblocking someone does not resubscribe them, and resubscribing someone does not unblock them. A contact who is both needs both.

​

Bot paused

Pause bot reply on a contact’s page is not a consent control. It is a human hand-off: it stops automations, sequences and booking reminders for that one contact while a person deals with them, and Resume bot reply puts them back. It has no bearing on whether the contact consented to anything.

​

Exporting a contact’s data

Contacts → Export streams a CSV of your contacts, honouring the channel filter you have applied. It needs the export permission. See Roles and permissions. The file has exactly seven columns, the same seven the importer reads: name, country_code, phone, tags, stage, notes, custom_fields. The country_code column is always written empty; the full number is already in phone, so a round trip back through CSV import still works. If you need to answer a data request properly today, you have to assemble it by hand from the contact’s page (Profile, Custom fields, Activity timeline, Channels, Internal notes and the conversation itself) or pull it through the API, which exposes considerably more of the record than the CSV does.

​

Deleting a contact

Delete contact (in the contact’s ⋯ menu on the Contacts list, or on the Pipeline board) reaches further than the name suggests. It removes the contact and cascades to their channel identities, their whole message history (the photos and files exchanged in those conversations are deleted from storage as well), their internal notes, their client profile, their tags, their uploaded documents, any letters generated for them, and their family links. DMLY then sweeps every one of its own tables that stores the contact’s id, around 38 of them, so the person is not left behind in a table nobody thought to name: their flow runs and captured answers, their conversation events, their broadcast and sequence enrolments, their calls and CSAT responses all go with them. The confirmation says Delete {name}? This cannot be undone., but for 30 days that is not quite true: the contact can be restored from Recently deleted.

​

Finance and booking records go too

That sweep includes the money and the diary. Deleting a contact destroys:

• their invoices, and the payments recorded against them, refunded ones included
• their orders, their subscriptions, and any saved payment method
• their appointments and their places in any class, past as well as future
• their account statement, credit balance and loyalty ledger entries
• their coupon and gift card redemptions, and their review requests

Nothing is kept back for accounting or legal reasons beyond the 30-day recovery copy. There is no invoice archive, and no anonymised stub is left in place of the person. Two things outlive the contact. The line items of a deleted invoice or order stay behind, holding amounts and item names with nothing that identifies the person and no invoice left to reach them through. And a gift card they bought or were given stays valid, because a card is redeemed by its code against an invoice and never needs the contact record; only the record of who redeemed it goes. Deleting needs the delete permission, so you can keep it away from most of the team via Roles and permissions. The same delete, with the same reach, is available through the API and through bulk delete on the contacts list.

​

Recently deleted

Every ordinary delete keeps a recovery copy for 30 days. That covers a single delete, a bulk delete, a delete through the API, and the contact merged away in a merge. Open Recently deleted from the Contacts header. It reads “Contacts deleted in the last 30 days. After that they are gone for good.” It needs the same delete permission. Each entry has two actions:

• Restore brings back the contact and the records deleted with them: message text, notes, invoices, payments, bookings and the rest. Attachments and document files do not come back, because they were removed from storage at the time of the delete.
• Delete permanently destroys the recovery copy at once, with nothing left to restore.

A contact that was merged away comes back as a person only. Their history moved to the surviving contact and stays there. The copy keeps up to 5,000 of a contact’s newest rows in each table; an entry that held more is marked Partial recovery. A daily job removes each copy once its 30 days are up. There is no anonymise or pseudonymise option and no retention policy you can configure; no contact is aged out for being old. Archiving is the one automatic deletion: an archived conversation is deleted 30 days later, and the contact goes with it if that was their only conversation. See Conversation status. A contact removed that way still lands in Recently deleted, but its archived messages are already gone and do not come back. If you need any of a client’s history for tax or dispute reasons, export, download or screenshot it before you delete.

​

What DMLY does not have

Being straight about the gaps is more useful than implying coverage:

• No contact-facing privacy page. There is no “request my data” or “delete my data” link you can give a contact. Shopify is the exception: with Shopify connected, DMLY handles Shopify’s customer data requests and customer redaction requests automatically. On a redaction, a contact who came only from the store and never wrote in is deleted (with the usual 30-day copy in Recently deleted), and any other matched contact has its store details redacted. Every other request is handled by you, by hand, in the dashboard.
• Only a partial consent record. DMLY records a STOP as a withdrawal, with the word the contact used, when it has a WhatsApp number or phone number for them. It records an opt-in in full only when it came through a WhatsApp popup growth tool: the consent wording shown, the page, the time, a hashed IP address and the browser details. The dashboard does not show that record. What the Inbox does show is a Consent given date in the conversation’s details panel, for a popup opt-in and for a visitor who ticked the consent box on the Live Chat pre-chat form. Other opt-in routes are not recorded. For proof of consent from any other route, keep it in a custom field or a note.
• No retention schedule for contacts. A contact is never aged out for being old. The one automatic deletion is archiving: an archived conversation, and a contact left with no other conversation, is removed 30 days later. See Conversation status.

​

Practical rules for a compliant workspace