Traiter les demandes sur les données personnelles

How a tenant answers data-subject requests with the built-in tools, and what the platform owner still has to do outside the product. See privacy-data-map.md for what is stored where.

This is engineering documentation, not legal advice. It describes what the software does. Whether that is enough for a given tenant, contract or jurisdiction is for the tenant and the platform owner (with their advisers) to decide.

Roles

• Each tenant (website) is the controller of its visitors’ and contacts’ data.
• The platform owner is the tenant’s processor, and uses sub-processors (below).
• In the product: owners and admins handle requests (Settings → Privacy & data); only the owner can export the whole workspace. Agents see none of this. API tokens cannot reach any of it.

Answering an access request (“send me everything you have on me”)

1. Verify the requester outside the product (e.g. reply to the address the request came from, or have them sign in to your own customer portal). The product cannot know who is asking.
2. Open the contact (Contacts → the person → ⋯ → Export or erase personal data…) or search the address in Settings → Privacy & data → Requests.
3. Read the preview:
   • Matched sessions — verified (identity signature), or the email channel for that address when the address is proven there: an inbound mail from it was authenticated by your mailbox provider (set the mail server name in Settings → Email channel → IMAP) or answered one of your team’s replies. A thread that only claims to be from the address (forged From:) is listed with the unverified sessions.
   • Unverified sessions that used this address — someone typed the address without proving it. Open those conversations before ticking Include these sessions: they may belong to someone else, or have been planted to receive another person’s data. Included sessions land in a separate, labelled folder.
4. Export data. Internal notes (private notes and internal timeline events such as assignments and status changes) are not included by default: your team wrote them and they may contain other people’s information (colleagues, other customers). Read them first; where they hold this person’s personal data they are generally in scope of the right of access — then tick Include internal notes.
5. When the job shows Done, download the ZIP (admins of this website only, for 7 days) and send it to the requester through a channel you trust. It contains summary.html (readable), data/*.json and conversations/*.json (machine-readable) and the files the person sent. Support staff appear by name only; other customers’ data is never included.
6. The request, the completion and each download are in the Audit log.

Answering an erasure request (“delete me”)

1. Verify the requester (as above). Check you have no legal reason to keep the data (open dispute, invoices, legal obligation). If you do, set a legal hold on the contact instead: erasure and retention then leave it alone, and the hold is audited.
2. Open the person (as above) → Erase…
3. Choose the mode:
   • Delete — profile, sessions, conversations and messages, files on disk, emails (incl. originals), AI answers and caches, campaign/sequence history, consents, import references, webhook logs mentioning them and earlier export files are removed.
   • Anonymise — conversations stay for your records and reports; names, addresses, phone numbers, IPs, location below country, custom data, page-address query strings and files are removed and a pseudonym (“Anonymised 3f9a1c”) replaces the name. Message text is kept unless you tick Also redact message text: known identifiers are replaced, but anything else the person wrote stays.
4. Decide about unverified sessions (left out: the address is still removed from them) and whether to keep blocking the address (only relevant if you had blocked them).
5. Read the counts per category, type the address to confirm, Delete permanently / Anonymise permanently.
6. The job runs in the background and is resumable: if it fails, Resume continues where it stopped (every step is idempotent). When done, open the Certificate — a signed JSON summary (counts per category, mode, who and when, the backup statement; no personal data) you can keep as evidence or send to the requester.
7. What stays, on purpose:
   • a suppression record: a keyed hash of the address marked “erased on <date>”, so a later CSV import or sync does not silently add the person back and email them (imports skip the row with Erased on request (do not contact); sequences never enrol them; a contact re-created later stays unsubscribed). This is standard practice and is not readable without the server secret;
   • the audit entries (who/when/mode/counts) and the certificate;
   • a contact.erased webhook event is sent to subscribed endpoints with opaque ids only — use it to erase the person in your own systems.
8. Tell the requester about the limits (see below), in particular backups.

Visitors cannot yet export or delete their own data from the chat widget; every request goes through the tenant as described here.

Retention

Settings → Privacy & data → Retention: per policy, how long data is kept. Defaults: conversations and files are kept forever (nothing changes on upgrade); technical logs have short periods (webhook logs 30 days, push receipts 7 days, import logs 30 days, AI caches 90 days, email originals 180 days, visitors who never chatted and page views 395 days, audit log 365 days). What would be deleted today is a dry run of the next nightly job. The Retention log lists what each run removed. Legal-hold contacts are never touched. Platform admins can cap every period platform-wide (/platform → Privacy & retention).

Visitor notice and consent

Settings → Privacy & data → Visitor notice: off, notice only (a line with your policy link under the message box) or ask for consent (visitors accept before their first message or upload — enforced by the server — and before the email card; the acceptance is stored with the policy version and is part of exports). Change the version when your policy changes — visitors are asked again. Visitor data (same page) holds “store visitor IP addresses” and “city-level location”.

Workspace export

Settings → Privacy & data → Workspace export (owner): contacts (CSV + JSON), conversations, every message (NDJSON), help center (JSON + Markdown), shortcuts, tags, departments, automations, settings, members and the audit log. No secrets (identity secret, integration passwords/keys, webhook signing secrets, API tokens) and no uploaded files. Available while the tenant is suspended. Download for 7 days, audited.

Limits

• Free text: anonymise keeps what people wrote unless text is redacted; only known identifiers are replaced. Delete removes conversations entirely.
• Unverified sessions are a judgement call for the admin; the tool shows them, it cannot know who typed.
• Public help-center votes are stored as a hash of IP + user agent and cannot be attributed to a person.
• Backups, server/proxy logs and copies outside the product (webhook receivers, inboxes, WHMCS, delivered push notifications) are not reached.
• Orphan uploads (a file uploaded but never sent in a message) cannot be attributed to a person; they are removed by the files retention policy if one is set.
• New features must register their tables with the personal-data registry; a test enforces it, but a feature that stores personal data in a column with an unusual name could still slip through review — the data map is the place to record it.