## 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](/hc/ajuda/articles/administration-modo-apresentacao-en), 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

1. Open **Settings → Governance & LGPD**.
2. 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.
3. 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.
4. Set the **audit trail retention (days)** — older events are pruned.
5. 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).
6. 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.

## See also

- [Presentation Mode](/hc/ajuda/articles/administration-modo-apresentacao-en)
- [Audit logs](/hc/ajuda/articles/administration-auditoria-en)
- [Custom roles and governance (RBAC)](/hc/ajuda/articles/administration-custom-roles-governanca-rbac-en)
- [Companies and relationships](/hc/ajuda/articles/contacts-crm-empresas-e-relacionamentos-en)