Our organization is reviewing our data retention and deletion practices to ensure full GDPR compliance, specifically around the ‘right to erasure’ requirements. We’re debating whether to implement a data archival strategy versus performing hard deletes when customers request data removal.
The archival approach would move account data to a separate archive object or external system, maintaining referential integrity for historical reporting while removing it from active Salesforce data. The hard delete approach would permanently remove the records from Salesforce entirely.
I’m particularly concerned about integration dependencies - we have several external systems that reference Salesforce Account IDs, and hard deletes could break these relationships. However, archival might not fully satisfy GDPR’s erasure requirements if the data is still technically accessible. What approaches have others taken to balance compliance requirements with operational needs?
Both approaches are defensible under GDPR Article 17, but they carry fundamentally different risk profiles and operational costs. The “right to erasure” does not mandate hard deletion by default — it requires that personal data no longer be processed for its original purpose. Pseudonymization or anonymization of retained records can satisfy erasure obligations if re-identification is technically infeasible. That distinction is the architectural pivot point here.
Core Trade-off Matrix
Criteria
Hard Delete
Archive + Anonymize
External Archive
GDPR Article 17 compliance
Strongest, clearest audit trail
Acceptable if anonymization is irreversible
Depends on jurisdiction and DPA interpretation
Referential integrity
High breakage risk
Preserved via placeholder/tombstone record
Preserved, but latency on lookups
Integration dependency risk
High — external systems lose FK resolution
Low — Salesforce ID persists as shell record
Medium — ID persists but data retrieval changes
Audit defensibility
Simple, point-in-time proof
Requires robust anonymization documentation
Requires cross-system audit chain
Reporting continuity
Broken for historical aggregates
Maintained with suppressed PII fields
Maintained, with query complexity
Salesforce storage cost
Reduced
Neutral to slightly increased
Reduced in SFDC; increased externally
Implementation complexity
Low
Medium
High
Key Technical Considerations
Hard delete path: Salesforce’s recycle bin retains records for 15 days (verify in your version) — a hard delete via API or Data Loader with permanentlyDelete=true bypasses this. You still need to scrub PII from related objects (Contacts, Activities, custom junction objects) and audit logs. Field History Tracking and Einstein Activity Capture are common PII leakage points that survive record deletion.
Archive + anonymize path: A tombstone pattern works well — replace all PII fields with null or a static token (e.g., GDPR_ERASED_[timestamp]), flag the record with a custom picklist or compliance metadata field, and retain the AccountId as a dead reference anchor. Your integrations resolve the ID without receiving personal data. Document the anonymization logic formally — your DPA will likely want to inspect it.
External archive path: Moving data to a data lake or vault before deletion buys you historical reporting fidelity, but you’ve now extended your GDPR data map. Every system holding that data independently triggers Article 17 scope. This increases your erasure surface area, not reduces it.
Integration Dependency Specifically
For external systems referencing Salesforce AccountId, the tombstone/anonymize approach is operationally superior. Hard deletes without a migration plan will produce broken foreign keys, failed API callouts, and silent data corruption in downstream systems. At minimum, publish a deletion event via Platform Events or Change Data Capture so consuming systems can handle the lifecycle transition gracefully.
The right answer depends on context / your requirements — specifically your DPA’s interpretation of anonymization adequacy, your integration architecture’s tolerance for dead-record resolution, and whether historical reporting continuity is a business-critical requirement.
This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
GDPR’s right to erasure is quite specific - if a customer requests deletion, you generally need to perform actual deletion, not just archival. Archiving to another system still means you’re processing personal data. However, there are exceptions for legitimate business interests like legal compliance or contract fulfillment. You need to document why you’re retaining data if you choose archival over deletion.
We implemented a hybrid approach. For GDPR erasure requests, we hard delete the Account record but first anonymize related data rather than deleting it entirely. For example, we keep Opportunity records but replace the Account name with ‘Deleted Account - [timestamp]’ and null out personal identifiers. This preserves reporting integrity while removing personal data. For integration dependencies, we built error handling in our middleware to gracefully handle deleted Account references.
From a legal perspective, GDPR Article 17 requires deletion unless you have a lawful basis to retain the data. Financial records with tax implications, contract履行 obligations, or legal defense needs can justify retention. If you archive data, you must ensure it’s not used for active processing and is secured appropriately. The key question is: do you have a legitimate interest that overrides the erasure request? Document your data retention policy clearly and apply it consistently. Pure archival without a legal basis won’t satisfy GDPR requirements.
Integration dependencies are a real concern with hard deletes. We’ve had issues where external systems crashed when Salesforce Account IDs they referenced were deleted. Our solution was to implement a ‘soft delete’ pattern - add a custom field ‘GDPR_Deleted__c’ and a deletion date, then filter this field out of all integrations and reports. The record technically exists but is completely excluded from processing. This preserves referential integrity while effectively removing the data from use. However, I’m not sure this fully satisfies GDPR’s erasure requirements - it might be considered pseudonymization rather than deletion.
You need to distinguish between different types of data and apply appropriate strategies. Personal identifiable information (PII) should be hard deleted or fully anonymized for GDPR. Transactional data without PII can be retained for legitimate business purposes. Consider implementing a three-tier approach: Tier 1 - PII fields are immediately nullified or deleted; Tier 2 - Account record is anonymized (name becomes ‘Deleted Account’, email nullified, etc.); Tier 3 - Non-PII transaction records are retained with anonymized references. This balances GDPR compliance with operational needs.
Here’s what we learned after implementing GDPR-compliant deletion across a complex Salesforce org with extensive integrations. The archival vs hard delete decision isn’t binary - you need a nuanced strategy that addresses both compliance and operational reality.
Understanding GDPR Right to Erasure:
GDPR Article 17 requires deletion of personal data when requested, unless you have a legitimate legal basis for retention. Key exemptions include: compliance with legal obligations (tax records, financial reporting), establishment or defense of legal claims, archiving for public interest purposes. Pure business convenience (like wanting to keep historical reports) is NOT a legitimate basis. If you cannot justify retention under GDPR’s specific exemptions, you must delete.
Data Archival vs Hard Delete Trade-offs:
Archival Approach:
Cons: May not satisfy GDPR erasure requirements unless data is fully anonymized, creates ongoing data governance burden, requires secure storage and access controls
Best for: Data you have legal obligation to retain (7-year financial records), aggregated analytics without PII, defending legal claims
Best for: True erasure requests without retention justification, duplicate or test data cleanup, accounts with no financial or legal implications
Handling Integration Dependencies:
Integrations breaking due to deleted Account IDs is a common challenge. Solutions we’ve implemented:
Cascade Delete Configuration: Review all integration touchpoints and implement proper error handling for deleted references. External systems should gracefully handle 404 responses when querying deleted Salesforce IDs.
Tombstone Records: Instead of hard delete, create a minimal ‘tombstone’ record that retains the Account ID but nullifies all PII fields. Add a ‘Deleted_For_GDPR__c’ flag and exclude these from all queries and integrations using global filter criteria.
ID Mapping Table: Maintain a custom object that maps deleted Account IDs to anonymized references (‘Account-12345-DELETED’). External systems can query this mapping to understand the account no longer exists without breaking referential integrity.
Integration Refactoring: Update integrations to use external IDs or natural keys instead of Salesforce IDs where possible, reducing dependency on specific record IDs.
Recommended Hybrid Strategy:
Implement a classification-based approach:
Class A (Full Erasure): Accounts with no financial transactions, no legal obligations, no ongoing contracts → Hard delete with integration error handling
Class B (Anonymization): Accounts with financial history or legal obligations → Retain record but anonymize all PII fields (replace name with ‘Deleted-[ID]’, null email/phone, remove addresses)
Class C (Retention with Justification): Accounts involved in active legal matters or regulatory investigations → Retain with documented legal basis, restrict access, set deletion date when justification expires
Implementation steps:
Create a custom field ‘Data_Retention_Class__c’ on Account object
Build a Flow that evaluates deletion requests and assigns appropriate class based on criteria (has open opportunities, has invoices in past 7 years, has open legal cases)
For Class A: Use Apex to hard delete with cascade handling
For Class B: Use Field-Level Security and automated anonymization to remove PII while keeping record shell
For Class C: Document retention justification in custom ‘Legal_Hold_Reason__c’ field
Schedule quarterly reviews of Class C accounts to reassess retention necessity
This approach satisfies GDPR’s erasure requirements while maintaining operational integrity where legally justified.