Consent Management Overview
Consent Management helps privacy, governance, and data teams document where authoritative consent records live and how those records map to the processing purposes described in privacy notices.
Use it when a data product is the source of truth for consent records from a consent management platform, preference center, or other customer-choice system. Qarion stores metadata about that source. It does not copy the consent records themselves.
When To Use Consent Masters
Designate a data product as a Consent Master when it contains records that answer questions such as:
- Which data subject gave or withdrew consent?
- Which consent type, topic, or purpose code was recorded?
- Which privacy notice version did the subject accept?
- Which processing purpose in Qarion does that raw consent value authorize?
Do not use Consent Masters for every product that contains personal data. Use Privacy Notices and RoPA mapping to describe ordinary processing. Use Consent Masters for the authoritative datasets that other teams should consult before using consent-based data.
Where To Work
| Surface | Use it for |
|---|---|
/consent-masters | Review the space or organization registry of designated consent masters. |
| Product detail -> Governance | Designate, edit, or revoke a product as a Consent Master. |
| Product access request modal | Enter an intended purpose and review the compatibility warning or confirmation. |
| Lineage graph | Spot consent master products in upstream or downstream data flows. |
The registry follows your current scope. In a space view it lists consent masters for that space. In an organization view it aggregates consent masters from spaces you can access and includes the source space.
Registry View
Open Consent Masters to review the current registry. The page shows:
- Total consent masters.
- Total mapped processing purposes.
- Number of distinct documented raw consent types.
- Product name and source space.
- Subject identifier column.
- Consent type column.
- Count and preview of mapped consent values.
Use search to find a consent master by product name, space, subject ID column, consent type column, raw consent value, mapped purpose name, or mapped purpose description.
Select the document icon on a row to inspect the consent type documentation. The modal shows the subject identifier, consent type source column, optional notice version column, raw consent values, mapped processing purposes, and purpose descriptions. Select the row action to open the product's Governance tab for editing.
Designate A Consent Master
Open the data product that contains the authoritative consent records and go to the Governance tab.
- In the Consent Master panel, select Designate data product.
- Choose the required Subject ID column. This should identify the data subject, customer, user, account, or other person-level key.
- Choose the required Consent type column. This column should contain the
raw consent value from the source system, such as
marketing_opt_inoranalytics. - Optionally choose the Notice version column if the dataset records which privacy notice version the subject accepted.
- Add purpose mappings by entering a raw data value, selecting a privacy notice, and selecting one of that notice's processing purposes.
- Save the designation.
After saving, the product is marked as a Consent Master, appears in the registry, and exposes a subject lookup SQL snippet.
Purpose Mappings
Purpose mappings connect the raw values in your consent system to the processing purposes that Qarion uses for privacy notices and RoPA reporting.
Example:
| Raw consent value | Mapped processing purpose |
|---|---|
marketing_opt_in | Marketing Analytics |
personalization | Product Personalization |
research_panel | Customer Research |
Mappings depend on privacy notices. If the purpose selector is empty, confirm that the relevant privacy notice and processing purposes exist for the space.
Keep raw values exact. The compatibility and documentation views use the stored
literal value, so marketing_opt_in and Marketing Opt In are different
values.
Lookup SQL
After designation, the Governance tab shows a generated SQL snippet for subject lookup. It uses the product's hosting location when available and includes:
- The subject identifier column.
- The consent type column.
- The notice version column, when configured.
- A placeholder subject ID filter.
Use this snippet as a starting point for investigations, DSR support, or pipeline filters. Replace the placeholder subject ID and adapt the SQL to the target warehouse before running it.
Purpose Compatibility During Access Requests
When users request access to a product, the request modal can ask for an Intended Purpose. Qarion compares that value with the product's authorized processing purpose.
| Result | Meaning |
|---|---|
| Compatible | The intended purpose matches the product's authorized processing purpose. |
| Warning | The intended purpose differs from the authorized purpose and may require DPO review. |
| Bypassed | The product has no authorized processing purpose, so the compatibility check cannot make a determination. |
The current check is a case-insensitive exact match against the product's declared processing purpose. It is a warning and routing signal, not a legal determination. Record the reason in the access-request justification when the purpose differs.
Edit Or Revoke
Use Edit mapping details from the product's Governance tab when the source schema, raw consent values, or privacy notice purposes change. Saving replaces the stored purpose-mapping set with the current rows in the panel.
Use Revoke designation when the product is no longer authoritative for consent. Revocation removes the consent-master flag, column mapping, and purpose mappings from the product. It does not delete the data product or any source consent records.
Permissions And Scope
Consent Master actions use the product's space context. You need access to the space and enough product governance permission to edit the product's Governance tab. Organization-level registry views are read-only aggregations across spaces you can access.
If you can see the registry but cannot edit a row, open the product and confirm that you are in the source space and have the required product governance permissions.
Good Practices
- Keep Consent Masters limited to authoritative consent datasets.
- Map consent values to active privacy notice purposes before relying on the registry for reviews.
- Use a stable subject identifier column that downstream teams can join against safely.
- Record notice versions when the source system has them.
- Review mappings whenever privacy notices, consent categories, or CMP values change.
- Treat generated lookup SQL as a template, not a production policy by itself.
Troubleshooting
| Symptom | What to check |
|---|---|
| No products appear in the registry. | Confirm a product has been designated from its Governance tab in the current space, or switch from organization to space scope. |
| The purpose selector is empty. | Create or update privacy notices and processing purposes before adding consent mappings. |
| Save fails with a required-column error. | Select both the subject ID column and consent type column. |
| Lookup SQL is missing. | Confirm the product is saved as a Consent Master and has a column mapping. |
| Purpose compatibility is bypassed. | Add an authorized processing purpose to the product's privacy/compliance metadata. |
| Organization registry omits a space. | Confirm you have access to that space and that the product is not archived. |