Gdpr Data Privacy

GDPR Data Privacy

Use this skill when a practitioner needs to implement GDPR or CCPA data privacy controls inside Salesforce: linking personal data to the Individual sObject, tracking consent through the native consent model, handling Right to Be Forgotten (RTBF) requests, processing data subject requests, or evaluating whether Privacy Center is required.

Before Starting

Gather this context before working on anything in this domain:

• Confirm whether Privacy Center is licensed. RTBF policy automation and data portability exports are only available through Privacy Center (a separately purchased add-on). Without it, all erasure logic requires custom Batch Apex.
• Identify every object that stores personal data in the org — Contact, Lead, PersonAccount, and any custom objects with PII fields. Erasure must cover all of them, not just Contact.
• Confirm the API version. The Individual sObject and IndividualId field on Contact/Lead/PersonAccount were introduced in API version 42.0 (Winter '18). Older managed packages may not expose IndividualId.
• Determine consent channels in scope. The native consent model is channel-aware: email, phone, fax, direct mail, social, and advertising are separate consent points with independent records.

Core Concepts

The Individual sObject (API v42+)

The Individual sObject (Individual) is a first-party Salesforce object that acts as the privacy and consent container for a natural person. It stores privacy preference flags at the person level rather than duplicating them on every related record.

Key fields on Individual:

• ShouldForget (Boolean) — signals that the data subject has invoked their right to erasure. This is a flag only. Setting it to true does not automatically delete or anonymize any data. Your org must respond to this flag through Privacy Center policies or custom Batch Apex.
• HasOptedOutOfSolicit — general solicitation opt-out.
• SendIndividualData — whether data may be shared with third parties.
• CanStorePiiElsewhere — whether personal data may be stored outside the org's primary region.

Contact, Lead, and PersonAccount each carry an IndividualId lookup field. Set this field to associate a person record with their Individual privacy container. One Individual record should represent one natural person; do not share a single Individual across multiple people.

Native Consent Model: ContactPointTypeConsent and ContactPointConsent

Salesforce provides two objects for fine-grained consent tracking:

ContactPointTypeConsent — channel-level consent. Represents a person's blanket opt-in or opt-out for a communication channel (e.g., "opted out of all email"). Key fields:

• ContactPointType — channel: Email, Phone, Fax, Web, MailingAddress, Social, or EngagementChannel.
• OptInStatus — OptIn, OptOut, PendingOptIn, or Unknown.
• EffectiveFrom, EffectiveTo — the consent window. These allow time-bounded consent (e.g., consent valid until a specific date or renewed at re-opt-in).
• PartyId — lookup to the Individual record.

ContactPointConsent — contact-point-specific consent. Represents consent for a specific email address, phone number, or other contact point. Key fields:

• ContactPointId — polymorphic lookup to the specific contact point (e.g., a Contact's email address via ContactPointEmail).
• OptInStatus, EffectiveFrom, EffectiveTo — same semantics as ContactPointTypeConsent.
• DataUsePurposeId — optional link to a DataUsePurpose record describing why data is processed (maps to GDPR Article 6 lawful basis).

Use ContactPointTypeConsent for channel-level blanket preferences. Use ContactPointConsent when you need per-address granularity or need to track consent for a specific processing purpose.

Right to Be Forgotten: Platform Behavior vs. Automation

RTBF (right to erasure) under GDPR Article 17 requires that personal data be deleted or anonymized when a data subject requests it and no legitimate retention basis overrides the request.

Salesforce does not automatically respond to ShouldForget = true. You need one of:

1. Privacy Center (licensed add-on): Provides a no-code policy engine. You define Erasure Policies that specify which objects and fields to delete or anonymize, and Privacy Center runs the erasure asynchronously when triggered by a Data Subject Request (DSR) record. Also provides Data Portability (export all data for a subject).

2. Custom Batch Apex: Without Privacy Center, you must write a Database.Batchable class that queries for records linked to Individuals where ShouldForget = true, then deletes or anonymizes them. This path requires careful handling of referential integrity and governor limits.

Anonymization over hard delete: In most orgs, hard-deleting a Contact breaks Opportunity, Case, and Order foreign keys. The recommended pattern is to anonymize (tokenize) the personal data fields — replace name, email, phone, and address with non-identifying tokens — while keeping the record shell for relational integrity. Delete only records that have no referential dependencies.

Common Patterns

Pattern 1: Individual Linkage and Consent Setup

When to use: Initial implementation of the privacy data model for contacts or leads who are EU/EEA residents, or any org adopting explicit consent tracking.

How it works:

1. Create an Individual record for each natural person. Set HasOptedOutOfSolicit, ShouldForget, and other flags as appropriate.
2. Set IndividualId on the related Contact, Lead, or PersonAccount to point to the Individual record.
3. For each communication channel the person has consented to or opted out of, create a ContactPointTypeConsent record linked via PartyId to the Individual.
4. For specific email addresses or phone numbers with their own consent events, create ContactPointConsent records linked to the ContactPointEmail or ContactPointPhone record.
5. Store EffectiveFrom and EffectiveTo on each consent record to represent the consent window.

Why not the alternative: Storing opt-out flags directly on Contact (e.g., HasOptedOutOfEmail) provides only a binary current state. It cannot represent time-bounded consent, per-purpose consent, or consent history. The native consent model supports audit trails and multi-channel granularity that Contact fields alone cannot provide.

Pattern 2: Right to Erasure via Batch Apex (No Privacy Center)

When to use: Orgs without Privacy Center that must respond to RTBF requests.

How it works:

// BatchForgotIndividuals.apex
// Queries Individuals with ShouldForget=true and anonymizes linked records.
// Run manually or schedule via System.scheduleBatch().

global class BatchForgotIndividuals implements Database.Batchable<SObject>, Database.Stateful {

    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator(
            'SELECT Id FROM Individual WHERE ShouldForget = true'
        );
    }

    global void execute(Database.BatchableContext bc, List<Individual> scope) {
        Set<Id> individualIds = new Map<Id, Individual>(scope).keySet();

        // Anonymize linked Contacts
        List<Contact> contacts = [
            SELECT Id, FirstName, LastName, Email, Phone, MailingStreet
            FROM Contact
            WHERE IndividualId IN :individualIds
        ];
        String token = 'ANON-' + System.now().getTime();
        for (Contact c : contacts) {
            c.FirstName     = 'ANON';
            c.LastName      = token;
            c.Email         = null;
            c.Phone         = null;
            c.MailingStreet = null;
        }
        update contacts;

        // Anonymize linked Leads
        List<Lead> leads = [
            SELECT Id, FirstName, LastName, Email, Phone, Street
            FROM Lead
            WHERE IndividualId IN :individualIds
                AND IsConverted = false
        ];
        for (Lead l : leads) {
            l.FirstName = 'ANON';
            l.LastName  = token;
            l.Email     = null;
            l.Phone     = null;
            l.Street    = null;
        }
        update leads;
    }

    global void finish(Database.BatchableContext bc) {
        // Optionally: send confirmation email, update DSR audit record
    }
}

Why not the alternative: Deleting Contact records breaks Opportunity, Case, and Order foreign keys, producing orphaned records or DML errors. Anonymization preserves referential integrity while fulfilling the erasure obligation for personal data fields.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Assess licensing and scope: Confirm whether Privacy Center is licensed. Identify all objects storing personal data (Contact, Lead, PersonAccount, custom objects). Determine which regulations apply (GDPR, CCPA, both) and whether the org processes EU/EEA residents' data.

2. Implement the Individual data model: For each natural person, create or ensure an Individual record exists. Set IndividualId on Contact, Lead, and PersonAccount records to link them. Define a trigger or flow to create an Individual automatically when a Contact or Lead is created for a regulated person.

3. Build the consent model: Create ContactPointTypeConsent records for each channel and each person, capturing OptInStatus, EffectiveFrom, and EffectiveTo. For specific contact points needing per-address or per-purpose consent, create ContactPointConsent records linked via DataUsePurposeId to a DataUsePurpose record that names the lawful basis.

4. Implement RTBF handling: If Privacy Center is available, configure an Erasure Policy for each object containing personal data and create a Data Subject Request workflow. If not, write and test Batch Apex that queries Individual WHERE ShouldForget = true, anonymizes linked records on all in-scope objects, and records fulfillment in a custom audit object or custom DSR record.

5. Handle data subject access requests (DSAR): Build an intake process (Experience Cloud form, email-to-case, or manual) that captures the data subject's identity and request type. Verify identity before processing. For data portability, Privacy Center exports a package; without it, write a report or export job across all related objects.

6. Test and validate: In a sandbox, set ShouldForget = true on test Individual records and execute the batch or Privacy Center policy. Verify all PII fields are anonymized or deleted across Contact, Lead, and custom objects. Confirm no broken foreign keys or orphaned records.

7. Document retention schedules: If any personal data must be retained beyond the erasure request (e.g., legal hold, financial records), document the lawful basis and configure Privacy Center retention rules or exception logic in Batch Apex. Do not silently skip erasure without a documented basis.

Review Checklist

Run through these before marking work in this area complete:

• Every Contact, Lead, and PersonAccount representing an EU/EEA natural person has IndividualId populated
• ContactPointTypeConsent records exist for each consent channel per person, with EffectiveFrom and OptInStatus populated
• RTBF mechanism (Privacy Center policy or Batch Apex) covers all objects storing personal data — not just Contact
• Anonymization is used instead of hard delete for records with FK dependencies
• DSR intake, verification, fulfillment, and audit-trail workflow is documented and tested
• Audit trail records each RTBF execution (who requested, when fulfilled, which records affected)
• Retention exceptions (legal hold, financial records) are documented with lawful basis
• Batch Apex is governor-limit safe: uses Database.QueryLocator, processes in batches of 200 or fewer

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. ShouldForget=true does nothing on its own — Setting Individual.ShouldForget = true is a data flag, not a system action. Salesforce does not automatically delete, anonymize, or suppress any record. If your RTBF implementation relies on setting this flag without responding automation, erasure never happens.
2. IndividualId is not auto-populated — Creating a Contact does not automatically create or link an Individual. Your org must implement a trigger or flow; Contacts created before this automation exists will have null IndividualId and be invisible to privacy-model queries.
3. Anonymization must cover all objects — Leads, PersonAccounts, and custom objects may all hold PII. Batch jobs scoped only to Contact are incomplete; a full data model audit must precede implementation.

Output Artifacts

Related Skills

• platform-encryption — use alongside this skill when fields must be encrypted at rest; encryption does not substitute for erasure
• sandbox-data-masking — use to prevent real PII from entering non-production orgs; complements RTBF but is a separate concern
• data-classification-labels — use to tag fields containing personal data, a prerequisite for building a complete erasure scope