2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)

Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)

Under global privacy legislation such as GDPR Article 17 ("Right to Erasure") and CCPA/CPRA consumer deletion mandates, individuals possess the enforceable right to request the permanent deletion of their personal data. For an enterprise utilizing Salesforce Data Cloud, fulfilling a Right to Be Forgotten (RTBF) request is an intricate technical operation. Because Data Cloud unifies billions of records across streaming and batch pipelines, consultants must understand the mechanics of the Consent API, cascading lakehouse deletion, storage compaction lifecycles, and downstream multi-cloud propagation.

---

The Consent API & Deletion Request Mechanics

Data 360 does not expose a "delete this row" button over the lakehouse. Every data subject deletion — the operational form of the right to be forgotten — is submitted through the Consent API, a Salesforce REST API resource that has existed since API version 48.0 and that gained Data 360 (cdp) mode for customer data platform profiles.

The Three Consent API Actions

The Consent API exposes three actions, and the exam expects you to pick the right one from a scenario description:

Submitting a Deletion Request

An authorized user or an automated privacy orchestration integration calls the shouldforget resource:

POST /services/data/v64.0/consent/action/shouldforget?ids=<comma_separated_ids>&mode=cdp&status=optin
Host: <MyDomain>.my.salesforce.com
Authorization: Bearer <access_token>

Parameters and Execution Behavior

• ids — required. A comma-separated list of IDs. Each ID must be present in a field that is mapped to Individual.Individual Id in the canonical data model. This is the single most common configuration failure: if the source identifier was never mapped to Individual.Individual Id, the request cannot resolve a subject and the deletion silently affects nothing.
• mode — optional, defaults to normal. Set it to cdp to target a Data 360 profile rather than a core CRM consent record. Omitting mode=cdp is the second most common failure.
• status — required. For shouldforget the value is optin; for processing it is optout.

A deletion request removes the specified individual record from the Individual DMO and its related DMOs. Processing is asynchronous, and Salesforce reprocesses each deletion request at 30 days, 60 days, and 90 days to catch records that arrived from upstream systems after the original request ran. That reprocessing window is a favourite exam fact, and it is also why "resubmit the request tomorrow" is never the right remediation for a straggler record.

The Multi-System Obligation

A Consent API deletion is scoped to Data 360. It does not propagate backwards into the systems that fed Data 360. Salesforce's guidance is explicit: the request must be submitted in every connected system and every Salesforce cloud that holds the subject's data. A consultant who deletes only in Data 360 leaves the source CRM, Marketing Cloud Engagement, and the external warehouse intact — and the next ingestion run will re-create the profile. That failure mode is covered in detail under the "Resurrection Trap" later in this section.

---

Cascading Deletion Across the Lakehouse Architecture

When a deletion request executes, Data Cloud cascades the erasure operation through every architectural tier of the customer data platform:

Consent API Deletion Request (Individual ID: 1001)
  │
  ├── 1. Lakehouse Storage Tier (DLOs)
  │      └── Tombstone markers applied; underlying Parquet files scheduled for compaction
  │
  ├── 2. Semantic Data Model Tier (DMOs)
  │      └── Cascades to Individual, ContactPointEmail, ContactPointPhone, etc.
  │
  ├── 3. Identity Resolution Engine
  │      └── Cluster nodes severed; Identity Graph recalculated on next scheduled run
  │
  └── 4. Unified Profile & Insights Tier
         └── Unified Individual deleted; Calculated Insights recalculated

1. Data Lake Objects (DLOs) & Lakehouse Storage Compaction

In Data Cloud's Hyperforce lakehouse storage, ingested data is written as immutable columnar Parquet files. When a deletion request is processed, the system writes a cryptographic "tombstone" metadata marker against the subject's records across all corresponding DLOs. During automated background storage compaction cycles, the storage engine reads the original data, strips all tombstoned records, and writes new compacted Parquet files, permanently erasing the physical bytes in compliance with statutory deadlines.

2. Canonical Data Model Objects (DMOs)

The deletion cascades automatically to all mapped canonical entities where the subject is mapped—including Individual, Contact Point Email, Contact Point Phone, Contact Point Address, and Contact Point App.

3. Identity Resolution Graph Restructuring

The customer's nodes and link edges are severed within the Identity Resolution graph database. If the deleted subject served as the bridge uniting two other source profiles, the Identity Resolution engine breaks the cluster during its next scheduled execution, recalculating the remaining records into separate, distinct Unified Profiles.

4. Engagement Data: Deletion vs. Anonymization

For time-series behavioral records (e.g., website clicks, mobile events, purchase history), organizations must balance privacy erasure against financial and accounting compliance (e.g., tax records requiring 7-year retention):

• Full Deletion: Purges all engagement records linked to the subject identifier.
• Pseudonymization / Anonymization: Scrubs all PII fields (name, IP address, user agent, contact points) while preserving aggregated transactional metrics (e.g., total order amount, product SKU count) linked to an anonymous hash, satisfying audit and reporting needs without violating GDPR.

Privacy Operation & Regulatory Lifecycle Comparison

---

Audit Trail Requirements & Compliance Ledgers

Under GDPR Article 5(2) ("Accountability"), organizations must be able to prove to regulatory authorities that a deletion request was honored. However, retaining the deleted customer's name and email in an audit log directly violates the erasure mandate!

Best-Practice Compliance Architecture: Maintain an immutable compliance audit record containing only:

• The unique privacy transaction request ID.
• A cryptographically salted SHA-256 hash of the requested identifier.
• Timestamp of receipt, processing start, and final deletion completion.
• Processing status (Completed) and the issuing system's authorization token.

---

Data Retention Policies & Storage Optimization

GDPR Article 5(1)(e) ("Storage Limitation") mandates that personal data must not be kept longer than necessary for the purposes for which it was gathered. In Data Cloud, unbounded retention of high-velocity streaming data also generates severe operational costs.

Configuring Retention on Engagement Data Streams

Engagement data (such as web browsing sessions, mobile application telemetry, and ad clicks) accumulates at petabyte scale. Data Cloud allows administrators to define explicit Retention Periods (e.g., 90 days, 180 days, or 365 days) at the Data Stream and DLO level:

• The system monitors event timestamps (EventTime).
• Parquet partitions with timestamps older than the configured threshold are automatically dropped during background lifecycle cleanup.
• Downstream Calculated Insights and segments automatically reflect the purged timeframe without requiring manual SQL truncations or deletion scripting.

---

Multi-Cloud Synchronization & The "Resurrection Trap"

[!CAUTION] The Multi-Cloud Downstream Disconnect Executing a deletion request via the Data Cloud Deletion API only deletes data inside Data Cloud. It does NOT automatically delete copies of that customer that were already exported to external activation targets (e.g., Marketing Cloud Data Extensions, Amazon S3 analytics buckets, Snowflake shares, or Meta Custom Audiences).

Consultant Mandate: A compliant enterprise architecture must orchestrate deletion across all endpoints simultaneously using platforms like Salesforce Privacy Center, MuleSoft, or event-driven webhooks.

[!WARNING] The Upstream "Resurrection Trap" Consider an enterprise where a customer submits an RTBF request. The consultant invokes the Data Cloud Deletion API, successfully removing the customer's Unified Profile and DLO records. However, the customer's record remains active in the source Salesforce Service Cloud CRM instance!

When the CRM batch data stream runs that evening, Data Cloud detects an updated or existing record in the source org, ingests it as a new record, maps it to DMOs, and runs Identity Resolution. The deleted customer is resurrected!

Preventative Design: Deletion must always be initiated in the primary system of record or orchestrated by an enterprise Privacy Hub that deletes or permanently flags the source record before or concurrently with the Data Cloud deletion.