Governance & LGPD

Overview

The Governance & LGPD module gathers, inside the account Settings, everything the operation needs to serve LGPD/GDPR day to day: the contacts' consent registry, data subject requests (export or anonymize/erase a contact's data), central message retention, the DPO data (Data Protection Officer) and the native audit trail. It also hosts Presentation Mode, which blurs sensitive data for demos and screen recordings.

Prerequisites

Administrator profile (or a custom role holding the governance permissions — governance management, data export, data erasure and audit viewing).
The Governance & LGPD feature enabled on the account. The Audit tab additionally requires the Audit Trail (Native) feature. If the area is missing, talk to the account owner.

Step by step

Open Settings → Governance & LGPD.
On the LGPD tab, fill in the DPO name and email and, if desired, enable automatically request and register inbound consent. Configure the global message, per-channel overrides, privacy-policy URL, and accepted affirmative/negative replies.
Set the message retention (days): messages of resolved conversations older than the limit are redacted automatically every day (0 disables it). Conversation retention (days) removes resolved, inactive conversations in small batches; linked contracts and active legal holds always suspend removal. The canonical audit ledger is preserved. Commerce payload retention (days) removes buyer-identifying data from old events while preserving aggregate revenue values.
Set the audit trail retention (days) — older events are pruned.
To serve a data subject: search the contact in the Data subject requests section and choose Export data (generates a JSON bundle with the contact's profile — including masked tax ID, country, address and billing address —, company memberships and relationships, consent history, conversations, messages and attachment manifest, and emails a notification; it does not include CRM deals, payments, tasks, contracts or bookings) or Anonymize (scrubs the identifying data — name, email, phone, identifier, attributes, fiscal document, address and the company memberships/relationships — preserving the conversation history).
Track progress in the Request history list, which refreshes automatically while requests are pending or processing. If loading fails, use Try again. When the bundle is ready, use Download bundle: the platform checks your permission again and issues a temporary link.

Settings & options

Manual/API consent: from the contact panel, read the history and append a declaration — purpose (data processing, marketing, cookies, custom), channel, granted or denied, and a note. The API also accepts structured evidence. History is immutable. A global (all) declaration is the current default; only channel declarations newer by event time/id are also current overrides. Older channel declarations remain visible but not current.
Automatic inbound consent: on the first inbound interaction for a contact/channel with no applicable data_processing declaration, the platform persists and sends the prompt through that channel's normal pipeline. The prompt is processed in the background, alongside bots, listeners, and automations — the inbound message never waits on it. A configured affirmative or negative reply appends a declaration with channel, response message, prompt message, and evidence. Automatic evidence stores technical IDs, the normalized matched token, and a SHA-256 digest — never the raw reply text.
Consent prompt wording, per language: the automatic prompt ships with built-in text, but you can write your own — and now per language. The text is chosen by the contact's language (falling back to the account language and finally to the wording you already had). A single text configured earlier keeps applying to every language: there is nothing to migrate. There is also a per-channel text, which wins over the general one. An {x} picker inserts the five accepted placeholders — {{contact_name}}, {{privacy_policy_url}}, {{dpo_email}}, {{affirmative_token}} and {{negative_token}}; anything else is stripped on send, and the platform refuses the save telling you which placeholder does not exist (in any of the languages). An empty field shows the built-in text that really goes out, and Restore default deletes your version of that language for real (the removal reaches the server, it does not just vanish from the screen).
Prompt preview and test: the preview renders the text per channel, with a real contact's name and the tokens the matcher accepts; the test really sends it to a conversation you pick. You validate the wording without waiting for the next inbound.
Legal holds: the Legal holds tab lists the conversations retention must never remove — not by age, not by inactivity. Search the conversation by contact, number or inbox, give the reason (a court order, say) and place it. A hold is released, never deleted: the record keeps who placed it, who released it and when, because that is precisely the evidence a legal hold exists to produce. Only administrators and roles with manage data governance place or release holds; export/erase holders can read the list to understand why a conversation survived a sweep.
Consent badge: the contact panel shows the state in force — Granted, Denied, or Pending. With more than one channel the badge shows the worst state, so a refusal can never hide behind a grant on another channel; hover it for the channel-by-channel reading. A channel the contact never declared on simply does not appear — absence is not pendency.
Unrecognized reply: if the contact answers with something that cannot be read as a decision, the platform stops asking and flags the conversation with Consent pending. Settle it with the contact and record the declaration by hand from the panel.
Campaigns: contacts who explicitly refused are removed from the audience. The preview reports how many were excluded, and the note appears only when a refusal actually shrank the list. Someone who was never asked, or whose grant expired, still receives it — asking for consent is the prompt's job, not the campaign's.
Deliberate boundary: this mode requests and records; it does not quarantine the inbound message, pause automations until a decision, or ever block outbound. The UI therefore makes no technical-blocking promise. If the operation's legal policy requires all processing to stop, enforce that restriction in the operational flow in addition to this registry.
Safe customization: the prompt can be global or channel-specific and supports only contact_name, privacy_policy_url, dpo_email, affirmative_token, and negative_token, each wrapped in double braces. Replies are matched case-insensitively and ignore accents and edge punctuation. An affirmative token cannot also be negative; the API rejects ambiguous configurations and legacy ambiguity never records a decision. Unsupported placeholders and Liquid tags are rejected; legacy values are stripped before sending so they cannot expose data.
Anonymize with message redaction: optionally the anonymization also redacts the contact's inbound message content and purges attachments.
Mandatory confirmation: anonymization/erasure requires typing the contact id — a guard against accidental destructive actions.

Use cases

Serve a formal data-subject request (LGPD art. 18) with an auditable receipt.
Periodically sanitize the base with central message retention.
Prove the marketing legal basis with the per-contact consent history.

Tips, limits & best practices

The export runs in the background; the requester receives an email that returns them to the authenticated Governance area. Only Administrators and roles with data export can issue the temporary bundle link; governance management or data erasure alone do not grant file access.
Anonymization does not delete the conversation — it deletes the identity. For full removal, use erasure (contact deletion), aware that the conversation history is removed with it.
Every governance action leaves an event in the audit trail (when enabled).
Prompt, grant, and denial have distinct audit actions; retries are idempotent and the contact row lock prevents two concurrent prompts.
Companies in DSR: a contact's export and anonymization already include their Companies memberships and relationships (names, roles, dates and notes). What stays separate is fiscal-document masking (Presentation Mode/RBAC) and the governance of the Company as an entity — see the Companies & relationships article.

Troubleshooting

The area is missing: the feature is not enabled on the account or your profile lacks the permission.
A request shows "Failed": check the error detail on the list and retry; the failure event is also recorded in the audit trail.
The prompt was not sent: check the Governance & LGPD feature, inbound consent control, and whether a global or channel declaration already exists. Any prior state (granted or denied) prevents another prompt. A prompt marked failed by the delivery provider is retried on the next inbound message, once per contact/channel.
A reply was not recognized: check the configured tokens; the message must match one complete token. Add required variants as comma-separated values.