What Survives a Salesforce Delete, and How to Erase Every Copy

Deleting a record in Salesforce removes it from the place you are looking, not from every place it lives. A deleted Contact can survive for 15 days in the Recycle Bin, indefinitely in the Field Audit Trail archive, for months in Einstein Activity Capture, until the next refresh in every sandbox, and indefinitely in Marketing Cloud, backups, exported files and the next spreadsheet someone imports. This article lists each copy, what Salesforce's own documentation says about it, and the order to erase them in.

Why "delete" is not the same as "erased"

Under GDPR Article 17, a person can ask you to erase their personal data "without undue delay", and Article 12(3) gives you one month from receipt to act, extendable by two further months for complex or numerous requests. The right covers the personal data you hold about them, not one record in one system. Article 19 adds that you must tell each recipient you disclosed the data to about the erasure, unless that proves impossible or involves disproportionate effort.

Salesforce makes this harder than it looks, because a delete in production is designed to be recoverable, and because data about one person is copied into places the delete never reaches. The right to erasure guide covers the legal side. This article is about the copies.

Where a deleted record survives

The rest of this article goes through each row.

1. The Recycle Bin: 15 days, then "eventually"

Salesforce Help is direct about it: "Deleted items remain in the Recycle Bin for 15 days, and during that time users can restore them. After 15 days, Salesforce schedules these items for permanent deletion from the Recycle Bin. Salesforce doesn't guarantee the exact time that the Recycle Bin permanently deletes these items."

Emptying the bin is faster but still not instant. The SOAP API guide says that after emptyRecycleBin(), records "can be queried using queryAll() for some time. Typically this time is 24 hours, but can be shorter or longer." Bulk API hardDelete skips the bin altogether, and the deleted records "become immediately eligible for deletion" — eligible, not gone. The "Bulk API Hard Delete" permission is disabled by default and has to be granted by an administrator.

Do not lean on the bin's capacity either way. Salesforce's documentation disagrees with itself: current Help says "There isn't a limit on the number of deleted records that the Recycle Bin can hold", while the SOAP API Developer Guide (updated 22 October 2026) still says an org can hold "up to 5,000 records per license" and removes the oldest when it hits that limit.

2. Field history, and the archive a delete never touches

Salesforce stores tracked field changes in history objects such as ContactHistory, with the old and new value of each change. Deleting the record removes those rows: "If you delete a record in your production data, the delete cascades to the related history tracking records." The same sentence continues: "but Salesforce doesn't delete the history copied into the FieldHistoryArchive big object."

That archive is Field Audit Trail. With it switched on, Salesforce archives field history after 18 months in production (after one month in sandboxes) "and stores all archived data until you delete it." Without it, field history is kept for up to 18 months, or 24 months via the API.

Removing a person from the archive takes deliberate work. FieldHistoryArchive is a big object, so records are deleted with Apex Database.deleteImmediate() or SOAP deleteByExample(); you have to supply every field in the big object's index, batches are capped at 50,000 records, and the user needs the "Delete From Field History Archive" permission (and "Delete From Field History" for live history).

One trap: if you anonymise a Contact instead of deleting it, the record survives — and so does its history, with the original values in the old-value column. Anonymising the record without dealing with its history leaves the personal data in place.

3. Archived activities: kept until someone deletes them

Salesforce archives events that ended more than 365 days ago and closed tasks due more than 365 days ago. Three facts make them easy to miss in an erasure. Through the API, "archived activities can only be queried via queryAll()". They "aren't included in reports". And "Salesforce doesn't delete archived activities, but you can manually delete them." A search that relies on reports or plain SOQL will not find them.

4. Einstein Activity Capture: not in your org at all

Emails and events captured by Einstein Activity Capture "isn't stored in your primary Salesforce database and isn't used to create Salesforce records that can be queried." Salesforce keeps it for the licence's retention period — 24 months by default with Sales Cloud Einstein-type licences, six months with Sales Cloud alone, adjustable through Support. Changing a contact's email address hides the captured data, but it stays stored until retention expires. Erasing it needs a separate delete request by email address, which Salesforce says can take up to a month. De-identified data derived from those activities is kept for up to two years, outside the retention policy.

No Apex or Flow inside your org can reach this store. It needs its own step in the runbook.

5. Copies inside the org that look like other data

Reporting snapshots save report results "to fields on a custom object" on a schedule. Each snapshot row is an ordinary record, separate from the Contact it came from, so deleting the Contact leaves it.

Files can outlive their record. Salesforce documents that removing a file from a record "doesn't affect the file on other records or posts, and the file remains in Files home", and that only deleting the file itself removes every version from every place it was shared. Salesforce's documentation does not say what happens to a file when the record it is attached to is deleted, so test it in a sandbox before you rely on either answer.

Chatter posts are hard deleted rather than recycled, and a post that appears in someone's feed because of an @mention "can't be deleted" there; it has to be deleted from the feed where the mention was written.

Privacy Center, if you license it, runs Right to Be Forgotten policies that can "obfuscate a customer's PII, move it to storage, or delete it." "Move it to storage" is not erasure, so check which action each policy takes. And the Individual object's "Forget this Individual" checkbox (ShouldForget) is described in Salesforce's object reference as a "preference to delete records and personal data related to this customer". Treat it as a record of the request; make sure a process acts on it.

6. Sandboxes: a copy of production as it was

Sandboxes do not follow production. Salesforce: "Customizations and data changes in your production org aren't reflected in your sandboxes." A Full sandbox holds all production data and can be refreshed every 29 days; a Partial Copy holds a sample and can be refreshed every five. A person you erased today is still in every Full sandbox created before today, available to every developer, tester and contractor with access to it.

You have two options. Refresh, and make sure the refreshed sandbox is masked so the next copy of production does not create a fresh exposure. Or find and delete or mask the person in each sandbox now. GDPR does not distinguish production from non-production; a sandbox copy is personal data you hold.

7. Marketing Cloud: two deletes, in the right order

This is where most erasures quietly fail. Deleting a Lead or Contact in Sales or Service Cloud removes the matching row from the Marketing Cloud Connect synchronized data extension, "but it doesn't delete the contact record from Engagement." That takes a separate Contact Delete in Contact Builder, and Salesforce recommends deleting "from Sales or Service clouds first, then … from Marketing Cloud."

Contact Delete itself has rules worth knowing:

• It starts with a suppression period that defaults to two days, which you can shorten to zero. Once the deletion runs it is final, and Salesforce cannot restore it.
• It removes the contact from lists and every sendable data extension, "including any tracking or preference information". It does not cover non-sendable data extensions outside a Data Designer population, FTP files or other sources; "You're responsible for deleting applicable information from those sources on your own."
• On Lock-and-Publish and Agency account structures, a deletion applies only to the account where it is made, so copies in other business units survive.
• Deleting the contact also deletes their opt-out preferences. If the same person is imported again later, they come back as a brand-new contact with no record that they unsubscribed.

That last point is why Salesforce itself recommends "retaining a list of deleted ContactKey and SubscriberKey values to prevent this reintroduction into your system."

If you also run Account Engagement (Pardot), check what its connector does when a synced lead or contact is deleted, and how your imports and API calls treat deleted prospects. Deleted prospects go to an Account Engagement recycle bin, and in some account types an API upsert by email searches deleted records by default and undeletes the match.

8. Data Cloud: up to 90 days, and order matters again

In Data Cloud, right-to-be-forgotten requests go through the Consent API's shouldforget action, which Salesforce describes as "permanently deleting PII (Personally Identifiable Information) data and any related records." It is not instant: "It can take up to 90 days to process your request," and "some records submitted for deletion remain visible" in the meantime. If Data Cloud ingests Marketing Cloud data, Salesforce's sequence is to submit the Data Cloud request first and the Marketing Cloud request 48 hours later, which "prevents the reintroduction of marketing subscribers into Data Cloud."

9. Backups and exports: copies you control, and copies nobody does

Salesforce Backup is a paid add-on. Two details matter for erasure: records stored in big objects — including the Field Audit Trail archive — are not backed up, and restoring a deleted record creates it under a new record ID. If your erasure log only lists record IDs, a restore can bring a person back in a form the log will not recognise. Log the identifiers you searched by, not only the IDs you deleted.

Data export files are deleted from Salesforce 48 hours after the notification email, not counting weekends. Once someone downloads the zip, the CSVs are copies outside Salesforce, and no Salesforce delete will ever reach them.

What regulators ask of backups differs by regime:

• The UK ICO expects erasure from backups too, but accepts that backup data may not be overwritable at once. The key is to put it "beyond use" until it is replaced on schedule, and you "must be absolutely clear with individuals as to what will happen to their data when their erasure request is fulfilled, including in respect of backup systems." (The ICO notes this guidance is under review after the Data (Use and Access) Act.)
• California's CCPA regulations (11 CCR §7022(d)) let a business delay deletion from archived or backup systems "until the archived or backup system relating to that data is restored to an active system or is next accessed or used for a sale, disclosure, or commercial purpose."

Either way, a restore is the moment the erasure has to be re-applied.

10. The next import: keep a suppression record

A deletion that the next Data Loader job, web form or integration sync quietly undoes was not much of a deletion. You need a minimal record of who was erased, checked before data comes back in.

The law makes room for it. CCPA §7022(e) says a business "may retain a record of the request for the purpose of ensuring that the consumer's personal information remains deleted from its records." In direct marketing, the ICO describes deleting everything "apart from a small amount that it keeps on its suppression list" as complying with the customer's right. Keep that record small. A hashed email is still personal data: under GDPR Article 4(5) and Recital 26, pseudonymised data "should be considered to be information on an identifiable natural person". Only genuinely anonymous data falls outside the Regulation.

What you are allowed to keep

Erasure is not absolute. Article 17(3) disapplies it "to the extent that processing is necessary" — among other grounds — "for compliance with a legal obligation" or "for the establishment, exercise or defence of legal claims." The words "to the extent" matter: a retention law that requires the invoice does not justify keeping the marketing history. Record which data you kept, under which ground, and for how long.

An erasure runbook for a Salesforce org

In order:

1. Discover every copy. All objects that hold the person, related records, archived activities (queryAll), files, field history and the Field Audit Trail archive, reporting snapshots.
2. Decide what stays. Contracts, legal holds, statutory retention. Document the Article 17(3) ground for each.
3. Delete or anonymise in production. If you anonymise, delete the field history too. Remove the person from FieldHistoryArchive with deleteImmediate().
4. Purge the Recycle Bin, or use hardDelete. Remember queryAll() can still see records for about a day.
5. Downstream, in Salesforce's order: CRM delete first, Data Cloud shouldforget, then Marketing Cloud Contact Delete 48 hours later. Check non-sendable data extensions, FTP files and other business units by hand. Check Account Engagement.
6. Einstein Activity Capture: submit the delete-by-email request.
7. Sandboxes: delete or mask in each, or refresh into a masked sandbox.
8. Backups and exports: put backups beyond use; record that a restore must re-apply the erasure; chase downloaded export files.
9. Suppression: add a minimal record so imports and syncs cannot bring the person back.
10. Evidence: log what was found, what was deleted or kept and why, when, and by whom. Answer within one month.

Where Cloud Compliance fits

Privacy Rights Automation handles steps 1 to 3 and step 10 inside your org: from an email address or customer ID it discovers related records across Sales Cloud, Service Cloud, Marketing Cloud and custom objects, deletes or anonymises them in governor-limit-safe batches that respect Master-Detail relationships, holds deletion while a contract or legal hold applies, and produces an audit trail you can export to PDF or CSV. Our DSAR automation guide walks through that workflow end to end. For step 7, Sandbox DataMasker masks personal data in a sandbox after each refresh, so the next copy of production is not a new exposure.

It runs in Salesforce, so it does not reach backups held elsewhere, files someone has downloaded, or the Einstein Activity Capture store. Those steps stay on the runbook.

If you would like to see an erasure run against your own org, book a demo.

Sources

• Regulation (EU) 2016/679 (GDPR), Articles 4(5), 12(3), 17 and 19, and Recital 26 (OJ L 119, 4.5.2016)
• California Code of Regulations, title 11, §7022 (Requests to Delete), as in force from 1 January 2026
• ICO, Right to erasure — "Do we have to erase personal data from backup systems?" (read 26 October 2026); ICO, Direct marketing guidance: respect people's preferences
• Salesforce Help, Manage the Recycle Bin in Lightning Experience; Field History Tracking Overview; Field Audit Trail
• Salesforce SOAP API Developer Guide v68.0 (emptyRecycleBin(), archived activities); Bulk API 2.0 Developer Guide (hardDelete); Big Objects Implementation Guide v68.0; Field Audit Trail Implementation Guide
• Salesforce, Sales Productivity (archived activities; Einstein Activity Capture data storage and retention); Analytics (reporting snapshots); Set Up and Maintain Your Salesforce Organization (data export, Salesforce Backup); Collaborate With Everyone (files, Chatter)
• Salesforce Help, Contact Deletion in Contact Builder; Data Deletion for Marketing Cloud; Synchronized Data Sources Best Practices
• Salesforce REST API Developer Guide, Use the Consent API with Data 360; Salesforce Help, Data Deletion for Data Cloud
• Salesforce Object Reference v68.0 (Individual, FeedItem, ContentDocument); Salesforce Help, Privacy Center; Account Engagement API v5 (Prospects)

All sources read on 26 October 2026. This article is general information, not legal advice.