Study guide
2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
Key Takeaways Explain This Topic AI
Data 360 fulfills Right to Be Forgotten requests through the Consent API shouldforget action with mode=cdp and status=optin, every ID passed in must be present in a field mapped to Individual.Individual Id, and Salesforce reprocesses each request at 30, 60, and 90 days.
Deletion in Data Cloud cascades through Data Lake Objects (DLOs), Data Model Objects (DMOs), and identity resolution graphs, unlinking clusters and purging unified profiles.
Deletion inside Data Cloud does NOT automatically recall or scrub data already exported to external downstream activation targets (such as Marketing Cloud Data Extensions, S3 buckets, or Snowflake shares); multi-cloud orchestration is required.
Engagement data retention policies must be configured on Data Streams and DLOs to automatically purge high-volume streaming/time-series data (e.g., 90-day web events) to optimize storage costs and satisfy storage limitation principles.
The upstream 'Resurrection Trap' occurs when a customer record is deleted in Data Cloud but remains active in an upstream source CRM or POS database, causing the profile to be re-ingested and reconstituted on the next scheduled sync.
Last updated: September 2026
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:
Action Regulatory Right What It Does in Data 360
processing Right to restrict processing Stops the profile from being used by Data 360 processes such as query and segmentation. Used with status=optout .
portability Right to data portability Permits export of the Data 360 profile data.
shouldforget Right to be forgotten / erasure Permanently deletes PII and related records. Once a profile is processed, it can never be used again. Used with status=optin .
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
Privacy / Lifecycle Operation Trigger Mechanism Target Architectural Tier Data Outcome Downstream Identity & Segmentation Impact
RTBF / Right to Erasure Consent API ( /consent/action/shouldforget?mode=cdp&status=optin ) DLOs, DMOs, Identity Graph, Unified Profiles Cryptographic tombstones applied; Parquet files purged during compaction Graph cluster severed; profile removed from all active segments
Restriction of Processing Consent API ( /consent/action/processing?mode=cdp&status=optout ) DMOs & Segmentation Query Engine Personal data retained in lakehouse storage but flagged restricted Excluded from segmentation evaluation and outbound activation exports
Engagement Retention Expiry Automated DLO Retention Schedule (e.g., 90/180/365 days) Engagement DLOs & Parquet Partitions Historical partitions dropped based on EventTime threshold Purged events omitted from Calculated Insights and segment lookbacks
Engagement Pseudonymization Batch Ingestion Transform / Data Prep Recipe Behavioral DLOs / Custom Engagement DMOs Direct PII stripped/hashed; transactional measures preserved Non-identifiable metrics retained for regulatory financial auditing
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.