GDPR Article 17 gives individuals the right to demand erasure of their personal data — and for Salesforce orgs, responding to that request is rarely as simple as deleting a Contact record. Delete a Contact and you cascade through open Cases, historical activity records, related Leads, linked custom objects, and potentially years of email correspondence stored in EmailMessage. The Salesforce GDPR right to erasure workflow requires a methodical approach: identify every location where the individual's personal data exists across your org, decide whether to delete or anonymise each record, execute that process without triggering automation errors, and document the outcome within the one-month response window GDPR requires. This guide covers how to do that reliably.
Erasure vs Anonymisation: What GDPR Actually Requires
The obligation under GDPR Article 17 is to erase personal data — not necessarily to erase records. The GDPR defines personal data as any information relating to an identified or identifiable natural person. Once the identifying information is removed and cannot reasonably be re-linked to an individual, the data is no longer personal data and the obligation is satisfied.
In practice this distinction is critical. Deleting a Contact record in Salesforce:
- Moves the record to the Recycle Bin (from which it can be restored for 15 days)
- Breaks lookup relationships on all related records
- Can trigger automation on related objects that expects a Contact to exist
- Corrupts historical reports that reference the Contact by ID
- Leaves field history tracking records and audit logs with the Contact ID but no accessible record
Anonymisation — replacing real personal data values with synthetic placeholders — avoids all of these problems. The record structure is preserved, relationships remain intact, automation does not break, and reports continue to work. The individual is no longer identifiable from the record. This is both legally sufficient under GDPR and technically safer for your org.
Where Personal Data Lives in Salesforce: A Complete Inventory
Most teams dramatically underestimate where personal data sits in their org. The Contact record is the obvious location, but a thorough erasure must cover every system record that contains identifying information about the individual:
| Location | What it Contains | Erasure Approach |
|---|---|---|
| Contact record | Name, email, phone, address, custom PII fields | Anonymise fields |
| Lead records | Original lead PII before conversion | Anonymise or delete if converted |
| EmailMessage | Full email body, From/To addresses, subject | Blank Subject/TextBody, anonymise addresses |
| Task / Event | Subject lines often contain names, email content in Description | Blank Description, anonymise Subject |
| Case | Customer name in Subject, case comments with PII | Anonymise Subject, blank comments |
| ContentDocument / Attachment | Files sent or received by the individual | Delete or replace with placeholder |
| Field History Tracking | Previous values of tracked fields | Cannot be edited — must be noted in erasure record |
| Custom objects | Any custom object with Contact lookup or stored PII | Audit per object, anonymise as needed |
| Chatter / Feed items | Posts mentioning the individual by name | Delete relevant FeedItem records |
Field History Tracking records deserve special attention: they store previous field values in the FieldHistoryArchive object, which is write-protected — you cannot update or delete individual history entries through the standard API. This is a known limitation that must be addressed in your erasure process documentation: note it explicitly, document that the current record has been anonymised, and record the date of anonymisation. Supervisory authorities in practice accept documented limitations in platform architecture as long as the accessible PII has been erased and the limitation is acknowledged.
The Erasure Workflow: Step by Step
A reliable right to erasure process for Salesforce follows five stages:
Stage 1 — Validate the Request
Before processing any erasure, verify the requestor's identity. GDPR does not require erasure requests to come from verified accounts, but you must take reasonable steps to confirm identity before erasing data — particularly in B2C contexts where someone could maliciously request erasure of another person's account. In B2B contexts, verification is typically simpler: the email address the request came from matches the Contact record in your org.
Stage 2 — Check for Legal Holds
GDPR Article 17(3) provides grounds on which erasure can be refused: legal obligations requiring retention (financial records under the Companies Act, clinical records under healthcare regulations), public interest tasks, and the establishment, exercise, or defence of legal claims. Check whether the individual is subject to any active legal hold, ongoing dispute, or regulatory retention obligation before processing the request. If a hold applies, document it and communicate the reason to the requestor within one month.
Stage 3 — Run Your Data Map
Use SOQL queries to identify every record across your org that contains the individual's identifying information. At minimum this means querying Contact, Lead, Case, EmailMessage, Task, Event, and every custom object with a Contact lookup. Store the resulting record IDs — you will need them for the anonymisation step and for your audit trail.
Stage 4 — Anonymise or Delete
Execute the anonymisation against all identified records. The recommended approach is a dedicated Apex batch job or Flow that accepts a Contact ID and processes all related records in a controlled sequence. Key considerations during execution:
- Disable automation temporarily if your flows or triggers react to field updates on these objects — you do not want an erasure triggering welcome email flows or case escalation rules
- Use a consistent anonymisation pattern (e.g.,
ERASED_[RecordId]for name fields,erased+[hash]@erased.invalidfor email) so anonymised records are identifiable as such without containing real PII - Log every record updated with the timestamp and the batch job ID — this becomes your audit trail
Field-level masking and erasure inside Salesforce — no middleware required
MaskEzee handles real-time PII masking, sandbox data anonymisation, and right-to-erasure workflows directly within your Salesforce org — without extracting data or building custom Apex.
See MaskEzee →Stage 5 — Document and Respond
Produce an erasure completion record: which records were found, which were anonymised, which were deleted, and any that could not be modified (Field History records) with the documented reason. Communicate completion to the requestor. Store the erasure record in a compliance log object — not in the anonymised Contact record itself, since that record should no longer be identifiable.
Don't Forget Sandboxes
If your org runs partial or full sandboxes, they contain copies of production data. A right to erasure request legally applies to every environment where the individual's personal data exists — including sandboxes. If you process the erasure in production but your sandbox from last month still has the original data, you have not fully complied.
The sustainable fix is not to process erasure across every sandbox individually — it is to ensure sandboxes never contain real personal data in the first place. Masking sandbox data at the point of refresh means you only ever need to process erasure in production, and your lower environments are always clean by design.
Frequently Asked Questions
Does GDPR require you to delete records from Salesforce entirely?
Not necessarily. GDPR requires erasure of personal data — removing the identifying information, not necessarily the record itself. Anonymising the fields that contain personal data satisfies the obligation while preserving data structure integrity. Deleting Contact records causes cascading relationship breakage and is usually the worse option.
What is the GDPR deadline for responding to a right to erasure request?
Under GDPR Article 12, controllers must respond within one calendar month of receipt. Where requests are complex or numerous, this can be extended by two further months, but the individual must be informed of the extension within the first month. Failure to respond within the initial one-month window is a procedural breach independent of whether the erasure is eventually completed.
Where does personal data hide in Salesforce beyond the Contact record?
EmailMessage records (full email content and addresses), Tasks and Events (subject lines, descriptions), Case comments, ContentDocument and Attachment records, custom objects with Contact lookups, Chatter FeedItem records, and Field History Tracking entries that stored previous field values. A complete erasure process must address all of these.
Does the right to erasure apply to data in Salesforce sandboxes?
Yes — if your sandbox contains real production data, the same GDPR obligations apply. The sustainable fix is to mask sandbox data at the point of refresh so lower environments never contain real personal data, meaning erasure only needs to be processed in production.
Can Salesforce's native Data Subject Request feature handle GDPR erasure?
Salesforce's Privacy Center provides a Data Subject Request workflow that handles core Contact, Lead, and Person Account fields. However, it does not cover all data locations — specifically third-party managed package data, custom objects with non-standard relationship configurations, or data synchronised from external systems. For most organisations with complex data models, Privacy Center is a useful starting point but not a complete solution.