SfSkills Domains Docs GitHub

Home / data / data-cloud-consent-and-privacy

data-cloud-consent-and-privacy

Use this skill when implementing consent management, data subject request processing, or data retention policies in Data Cloud — including the ssot__ContactPointConsent__dlm DMO, consent-aware segmentation filters, GDPR/CCPA data deletion requests via Privacy Center or Data Deletion API, and per-DLO retention policy configuration.

Open the skill folder on GitHub

Data Cloud Consent and Privacy

This skill activates when a practitioner needs to implement consent enforcement, data subject request processing (GDPR/CCPA), or data retention policies within Data Cloud. It covers the Contact Point Consent DMO model, consent-aware segmentation, deletion request workflows, and retention configuration. It does NOT cover CRM-layer consent (ContactPointTypeConsent on Salesforce org objects) — use the gdpr-data-privacy skill for that.

Before Starting

Gather this context before working on anything in this domain:

Core Concepts

The ssot__ContactPointConsent__dlm Data Model Object is the canonical consent record in Data Cloud. Each record links:

Consent enforcement requires explicit filtering on this DMO in every segment. The platform does NOT automatically exclude opted-out individuals from query results or segments.

This is the single most critical concept: creating a consent record in ssot__ContactPointConsent__dlm does NOT block an opted-out individual from appearing in a segment. Segment builders must add explicit filter rules that join to the Consent DMO and exclude opt-out records. Without this explicit filter, segments will include opted-out individuals.

Data Use Purpose

A Data Use Purpose defines the business context for consent (e.g., "Marketing Email", "Product Analytics"). Consent records are linked to a specific Data Use Purpose. Segments for a given marketing channel must filter consent specific to that channel's Data Use Purpose — a blanket "marketing" consent record does not cover all channels if purposes are defined granularly.

Deletion Requests: Right to Be Forgotten

Data subject deletion requests (GDPR Right to Be Forgotten, CCPA Right to Delete) must be submitted via:

Processing takes up to 90 days. Deletion propagates across the unified profile and all related DMO records linked to the resolved identity. It does NOT automatically cascade to:

Practitioners must handle downstream cascade deletion separately.

Data Retention Policies

Data retention policies are configured per Data Lake Object (DLO) in day-based increments. There is no platform-enforced minimum or maximum retention window. Retention policy deletion is automatic — records older than the configured period are purged. Policies must be designed before data is ingested to avoid retaining data longer than required for compliance.

Common Patterns

When to use: Any segment targeting individuals for marketing, analytics, or activation must exclude opted-out individuals.

How it works:

In Data Cloud Segment Builder, add a related filter on ssot__ContactPointConsent__dlm:

Filter condition:
  ssot__ContactPointConsent__dlm.DataUsePurpose = 'Marketing Email'
  AND ssot__ContactPointConsent__dlm.Status = 'OptIn'

This joins the segment to the Consent DMO, returning only individuals with an active opt-in for the specified Data Use Purpose.

Why not rely on default behavior: Without this explicit filter, the segment returns ALL individuals regardless of consent status. Sending to opted-out individuals violates GDPR/CCPA and risks regulatory penalties.

Pattern 2: Programmatic Deletion Request via Data Deletion API

When to use: Bulk or automated processing of Right to Be Forgotten requests received from multiple channels.

How it works:

# POST to Data Deletion API
import requests

headers = {
    "Authorization": f"Bearer {dc_token}",
    "Content-Type": "application/json"
}

deletion_request = {
    "identifiers": [
        {
            "type": "email",
            "value": "user@example.com"
        }
    ]
}

resp = requests.post(
    f"{dc_base}/api/v1/privacy/deletion",
    headers=headers,
    json=deletion_request
)
job = resp.json()
# Monitor job_id for completion — processing may take up to 90 days

Why not use Privacy Center for bulk: Privacy Center is UI-based and not suitable for programmatic bulk processing. The Data Deletion API handles automated DSAR processing at scale.

Decision Guidance

SituationRecommended ApproachReason
Segment for email marketingAdd OptIn filter on ssot__ContactPointConsent__dlmConsent not auto-enforced
GDPR Right to Be Forgotten requestPrivacy Center or Data Deletion APITriggers 90-day erasure across unified profile
Data retention past legal requirementConfigure DLO retention policy in daysAutomatic purge after configured window
CRM-layer opt-out (Contact object)gdpr-data-privacy skillDifferent layer — CRM ContactPointTypeConsent
CCPA Do Not SellMap to specific Data Use Purpose opt-outNo built-in CCPA purpose — configure custom purpose
  1. Confirm that ssot__ContactPointConsent__dlm is populated with consent records linked to the relevant Data Use Purposes — check in Data Cloud Data Explorer.
  2. For every segment, add an explicit consent filter joining to the Consent DMO for the applicable Data Use Purpose and Status = OptIn.
  3. For deletion requests: collect identifier type and value (email, phone, etc.) and submit via Privacy Center or Data Deletion API.
  4. Monitor deletion job status — processing takes up to 90 days.
  5. Identify all downstream systems that received data from activations and initiate cascade deletion separately (e.g., ad platform suppression lists, Marketing Cloud contact deletion).
  6. Configure DLO retention policies before data ingestion begins to ensure compliance from day one.
  7. Audit segment definitions quarterly to confirm consent filters are still correctly defined as Data Use Purpose definitions evolve.

Review Checklist

Salesforce-Specific Gotchas

  1. Consent Is Not Automatically Enforced — Creating a consent record in ssot__ContactPointConsent__dlm does NOT prevent opted-out individuals from appearing in segments. Explicit filter rules must be added to every segment. This is the most common compliance gap in Data Cloud implementations.
  2. Deletion Does Not Cascade to External Systems — Privacy Center and Data Deletion API erasure propagates across the unified profile in Data Cloud but does NOT reach ad platforms, Marketing Cloud contact records, SFTP exports, or other downstream systems that already received the data. Cascade deletion must be orchestrated separately.
  3. No Platform-Enforced Minimum/Maximum Retention Window — Retention policies can be set to any number of days. There is no guard rail preventing retention periods that are too long for GDPR compliance. Practitioners must design retention policies based on legal requirements, not platform defaults.
  4. CCPA Do Not Sell Has No Default Data Use Purpose — Data Cloud does not ship with a pre-built "Do Not Sell" Data Use Purpose. Organizations must create a custom Data Use Purpose and map CCPA opt-outs to it explicitly.
  5. Consent Write Propagation Latency — After a consent record is created or updated in ssot__ContactPointConsent__dlm, it may not be immediately reflected in segment membership due to the DSO → DLO → DMO pipeline lag. Do not assume real-time consent enforcement.

Output Artifacts

ArtifactDescription
Consent-aware segment filterSegment Builder configuration joining to ssot__ContactPointConsent__dlm with OptIn filter
Deletion request scriptPython automation for Data Deletion API DSAR submission
DLO retention policy planPer-DLO retention window (days) mapped to data category compliance requirement
Downstream cascade deletion checklistList of external systems requiring cascade deletion after Data Cloud erasure

Package files