Someone writes in and asks you to delete their data. Depending on where you and they are, you may have a legal clock running. This guide is about the mechanics: what the erasure tool in your dashboard actually does, how to check it before you commit, and the one detail that decides whether your chat history is included or quietly left behind.
This is not legal advice, and the tool is not a compliance programme. It is a reliable way to remove one person from your records, which is the part you will be doing by hand at two in the afternoon with an email open in another tab.
Naming the person
The erasure screen identifies a person by email address, phone number, or both. You must supply at least one; supplying neither is rejected outright.
Everything else follows from those two fields. There is no name search, no fuzzy matching and no account picker — which is the right call for a destructive operation, because a near-match on a common name is exactly the kind of mistake you cannot undo. It also means the quality of your answer depends entirely on getting the correct identifiers before you start.
Spend a moment on that. The person emailing you from a personal address may have chatted from a work one. Ask them, or search your tickets first, and collect every address and number they have used with you. Two runs with two addresses is a perfectly good way to handle it.
The dry run is the whole safety model
There are two buttons, and the difference between them is the difference between a report and a deletion.
Preview runs every query in counting mode. Nothing is modified. You get a row per category of data with a count and a status marking it as something that would be deleted. This is your evidence step, and it is worth taking a screenshot of it before you proceed — after the erase, those numbers are unreproducible by definition.
Erase runs the same queries as deletions. There is no additional confirmation beyond the button itself, so read the preview first, every time.
The preview is also deliberately more forgiving than the erase. If one category cannot be queried — an optional feature your account has never used, so the table is not there — the preview marks that row unavailable and carries on reporting the others. The erase does not tolerate errors at all, for reasons in a moment.
A preview that reports zero across the board is a real answer, not a failure. It usually means the identifier is wrong, so check it before you tell the requester you held no data on them.
What gets deleted, and in what order
An erasure walks eleven categories, and the order is not cosmetic — dependent records are removed before the records they hang off, so nothing is orphaned partway through:
- Ticket comments, ticket activity, and satisfaction responses attached to their tickets
- Linked identity channels — the messaging accounts tied to that person
- Visitor events, then AI transcript messages and AI tool invocations
- The tickets themselves
- Chat session records, the visitor profile, and finally the customer identity
Every one of those statements is scoped to your own account. There is no way to reach another tenant's data from this screen, whatever you type into it. Each statement is also guarded against a missing table, so a category your account never populated is skipped rather than becoming an error.
The same logic is available through the API for anyone automating this, and the two implementations are locked against each other by a test so they cannot drift apart.
Email finds more than phone does
This is the detail to take away from this page.
Tickets, visitor profiles and identities are all found by either email or phone. But three categories — chat session records, AI transcript messages and AI tool invocations — are matched on the email address only. Chat sessions are keyed on the visitor email captured at the time, and the AI records hang off those sessions.
The consequence is concrete: an erasure run with a phone number and no email address will not remove chat history or AI transcripts. The run will succeed. The preview will show zero for those categories, which reads exactly like having nothing to delete rather than like being unable to look. You would report the request complete in good faith, with the conversations still on file.
So make this your rule: always run with the email address. If a request arrives with only a phone number, find the address first — search your tickets and contacts for that number, and use the address recorded against it. If genuinely no email address exists for that person, say so in your internal note, because it changes what the zero counts mean.
If someone used several addresses, run the erasure once per address. The operation is safe to repeat; a second run over already-deleted data simply reports zeros.
Why a failure leaves nothing half-erased
The erase runs as a single transaction. If any step fails, the entire operation is rolled back and you are told it was rolled back — not that it partly worked.
That is the correct behaviour for this operation, and it is worth understanding why. A partial erasure is the worst possible outcome: you would have destroyed the evidence needed to reproduce the request while leaving records behind, and you would have no reliable way to tell which. All-or-nothing means a failed run leaves you exactly where you started, free to retry.
If you do see a rollback, do not simply hammer the button. The message carries the underlying reason; the common causes are a database under load or a schema that has not been updated for a feature you recently enabled. Retry once, and if it fails again, raise it rather than working around it.
What this does not reach
Be honest with yourself about the boundary of the tool, because the request you received is about your whole organisation, not about one screen.
It removes the person's records from your live chat, ticket and AI data. It does not touch backups, and it cannot reach anything you exported — the CSV in someone's downloads folder, the rows you pushed into your CRM, the chat transcript pasted into an internal thread, the notification that went to a chat channel. Every integration you have switched on is another copy you are responsible for.
Make a short written list of those destinations once, and keep it beside your erasure procedure. Working it out fresh under a deadline is how copies get missed.
The related lever is retention. Every conversation you keep past its usefulness is one more record you will have to find and erase later. A retention window that actually runs is the thing that makes future requests small.
What to record
For each request, keep four things: the identifiers you ran it with, the preview counts, the confirmation that it completed, and the date. That is a defensible record of what you did and it takes a minute.
Over time, watch how long requests take you end to end. If it is climbing, the cause is usually the search step rather than the deletion — people arriving with one identifier and your having to reconstruct the rest. Capturing a consistent email address at the start of a chat pays for itself here more than anywhere else.