How to Process a GDPR Right to Be Forgotten Request

When a customer asks to have their data erased under GDPR Article 17, you don’t need to file a support ticket with engineering — you can start, track, and prove the deletion yourself. This article walks through initiating a request, understanding the scope preview, waiting out the grace window, and producing the deletion certificate the customer can keep as evidence.

Erasure here is contact-scoped: it removes one customer’s data across the conversation graph, related records, storage objects, hosted call recordings, and analytics/cache copies. It does not delete other customers’ data, and it cannot be scoped by search or bulk-selected — it always starts from a specific customer.

Who can do this

Initiating and managing erasure requests requires the privacy.manage permission, which is currently granted to owners only. If you don’t see the delete option on a customer record, you don’t hold this permission — ask an owner on your team to run the request, or to add you as a privacy holder so you’re kept in the loop by email.

Privacy holders are the people notified whenever a request is created and again 24 hours before it executes, even if they didn’t initiate it themselves. Make sure the right people are set up to receive these so a request isn’t missed or forgotten during the grace window.

Step 1: Start the request from the customer

There is no free-search picker for this — you always start from the person whose data you’re erasing:

1. Open the customer record, or open the contact card from within a conversation.
2. Choose the option to delete the customer’s data.
3. Atender computes and displays the frozen scope preview — the full set of data that will be erased if you confirm.

The scope is “frozen” at this point: it’s a snapshot of everything currently linked to the contact, and it’s what gets archived and deleted later, even if new activity happens on the contact in the meantime (see what happens during the grace window).

Step 2: Review the scope preview and confirm

The scope preview is not a single number — it’s broken out by category (conversations, messages, attachments, call recordings, and other linked records), and each category can be expanded in a drill-down slide-out so you can see exactly what’s included before you commit. Use this to sanity-check that you’re erasing the right customer, especially if the contact has multiple merged identities or channels.

Once you’ve reviewed the scope:

1. Set the grace window — the waiting period before erasure executes. This can be set anywhere from 2 to 30 days; your tenant has a default (7 days out of the box) that’s pre-filled, and it can’t be set below a 48-hour hard floor regardless of what the tenant default is configured to.
2. Type the customer’s name to confirm. This typed-name confirmation is required before the request can be created — it’s the last checkpoint before the clock starts.

Once confirmed, the request enters pending status.

Step 3: The grace window

While a request is pending:

• It’s team-visible — anyone with access to the conversation or customer record sees an amber banner indicating a deletion request is in progress for this contact.
• It’s cancellable. If the customer changes their mind, or the request was started in error, cancel it from the banner or from the request’s detail view in Settings before the grace window elapses. Cancelling stops execution entirely — nothing is archived or deleted.
• Privacy holders get an email when the request is created, and another reminder 24 hours before it’s due to execute, giving the team one last chance to catch a mistake.
• A contact can only have one active request at a time — you can’t create a second erasure request while one is already pending or executing for the same contact.

If nobody cancels it, the request automatically moves to executing once the grace window ends.

Step 4: Monitor and manage requests in Settings

Go to Settings → Privacy & Data Requests to see every erasure request for your tenant in one place, not just the ones tied to a conversation you happen to have open.

From this page you can:

• Set the default grace window applied to new requests (still bounded by the 2–30 day range and the 48-hour floor).
• See every request’s status, with a paginated list showing status and summary details (not the full internal evidence or scope payload):

• Pending — Confirmed, grace window running, still cancellable
• Executing — Grace window has elapsed; archival and deletion are in progress
• Completed — Erasure finished; a deletion certificate is available
• Failed — Execution hit an error; the request needs attention (see below)

• Cancel any request still in the pending state.
• Download the deletion certificate for any completed request.

The deletion certificate

Once a request reaches completed, a deletion certificate becomes available for download from the request’s detail view. It documents, per data category, what was found and erased — this is what you hand to the customer (or to a regulator) as proof that the erasure actually happened, not just that it was requested.

If a request fails

A failed status means something went wrong during execution and the erasure did not fully complete — it does not mean the request was abandoned. Failed requests are retried automatically as part of routine reconciliation, and no request is left “failed” indefinitely with its underlying data retained forever: the archived data tied to a failed request is still subject to the same retention clock as a successful one and is purged and scrubbed on schedule. If a request stays in failed status for an extended period, escalate it — don’t just re-initiate a second erasure for the same contact, since only one active request per contact is allowed at a time.

Things to keep in mind

• Erasure is irreversible once execution completes. The grace window and typed-name confirmation exist specifically to give you a safety margin before that point — use the drill-down preview to be sure before you confirm.
• New conversations or activity created on the contact after the scope was frozen are not silently swallowed into the original request — they’re disclosed separately on the request detail so nothing is deleted without visibility into it.
• Merging a contact that has an active deletion request is blocked until the request finishes or is cancelled, to avoid mixing an in-flight erasure with unrelated history.