Truncate
Truncate in Salesforce is the action of permanently removing every record from a custom object while preserving the object metadata (fields, validation rules, layouts, relationships, sharing rules).
Definition
Truncate in Salesforce is the action of permanently removing every record from a custom object while preserving the object metadata (fields, validation rules, layouts, relationships, sharing rules). The operation is faster than a bulk delete because it skips the recycle bin, skips record-level sharing recalculation, and skips fire-by-fire trigger execution. It is the right answer when an admin wants to reset a custom object back to empty without rebuilding the object definition.
Truncate is available only for custom objects and only when the object has no related lists, no analytics snapshots tied to it, no remote sites that depend on it, and a few other constraints. Standard objects (Account, Contact, Opportunity, Lead, Case) cannot be truncated through the Salesforce UI; the only way to empty them is record-by-record delete or a mass delete with Data Loader. The feature is intentionally limited because the consequences are irreversible.
How Truncate works, what blocks it, and what it costs you
What Truncate does and what it does not do
Truncate empties the data on a custom object. The metadata (the object itself, every field, every validation rule, every layout, every list view, every sharing rule, every Apex trigger and class that references the object) is untouched. Records that were related to the truncated object through lookup or master-detail relationships have their links broken if they pointed at the now-deleted records; the parent records on the other side of the relationship remain. The Recycle Bin is not populated; truncated records are gone immediately and cannot be undeleted through standard Salesforce flows. There is no way to recover them other than restoring from a backup.
What blocks a Truncate
Salesforce will refuse to truncate a custom object that has any of the following: it is referenced in an analytic snapshot, it is referenced by a Salesforce Site, it is part of a managed package, it has external ID fields that other objects depend on for cross-org lookups, or it has an active Apex trigger that would prevent the operation. The exact list of blockers is documented in the Salesforce help article; Salesforce surfaces a clear error message when one of them is hit. The standard fix is to remove the blocking reference (delete the analytic snapshot, decouple from the Site, archive the managed package version) before retrying. The blockers exist to prevent accidental data loss in cases where the truncated records had a downstream dependency that would silently break.
Truncate versus bulk delete versus delete-all
There are three ways to empty a Salesforce object. Truncate (UI-driven, custom objects only) is the fastest because it skips the per-record overhead. Bulk delete through Data Loader or Bulk API is the universal option; it works on every object but takes longer because each record fires triggers, sharing recalcs, and recycle bin entries. Delete-all through SOQL with a soft-delete query is slower still and is rarely used. Pick Truncate when the object is a custom one with no blockers and you need a clean reset. Pick bulk delete when the object is standard or when you need records to go through triggers (for audit logging, for example). Pick delete-all when you need to preserve the recycle bin for recovery in case you change your mind within 15 days.
When Truncate is the right answer
The textbook use case for Truncate is sandbox refresh cleanup. After a sandbox refresh, custom objects often contain data that needs to be discarded so testers start with a clean slate. Truncate is also the right answer when a custom object was used for an experiment and the experiment is over; the object metadata may still be useful for other features but the data is no longer relevant. A third case is data migration cutover: after the cutover from the old system, the staging custom objects can be truncated to reclaim storage. The common thread is the object metadata is staying and the records have to go. Anything more nuanced than that (selective delete, archival, soft delete with recovery) uses a different tool.
Permissions, storage, and the operational cost of Truncate
Only users with the Modify All Data permission can truncate a custom object; standard users without it see no Truncate button. The operation runs synchronously for small objects (up to a few thousand records) and asynchronously for larger ones. Storage reclamation happens immediately, so a Truncate on a 10 GB custom object frees 10 GB of storage for the org. Because there is no recycle bin entry, the storage frees up in one step rather than the 15-day delay that ordinary delete operations carry. From an audit perspective, Truncate writes an entry to the org audit log but does not preserve any record-level history. If your industry requires record-level audit trails, do not Truncate; use bulk delete with a soft-delete flag instead.
Recovery, backups, and the irreversibility problem
Truncate is irreversible from the platform perspective. Once the records are gone, no Salesforce-native tool can bring them back. The only recovery path is a Salesforce-supported backup (Salesforce Backup and Restore, Own Company Backup, or an industry-standard backup tool like OwnBackup, AutoRABIT Vault, or Spanning). Without one of these in place, a Truncate that turns out to be a mistake is unrecoverable; Salesforce standard support team cannot restore individual record sets from cold backups. Before clicking Truncate, confirm a recent backup is available. Many orgs require a manual export of the affected object data to S3 or a similar archive immediately before any Truncate, as a tactical safety net even when a backup tool is in place. Make the backup step part of the runbook.
Running a safe Truncate on a custom object
Truncating a custom object is straightforward in the UI but consequential in effect. The five-step runbook covers: confirm a recent backup exists, validate the object has no blockers, take a fresh export of the data as a tactical safety net, run the Truncate from Setup, and validate the org is clean and downstream dependencies are still intact. Skip any of these and the Truncate either fails partway, takes data you did not intend to lose, or breaks downstream automation that referenced the truncated records by ID.
- Confirm backup and take a fresh export
Open your backup tool (Salesforce Backup, OwnBackup, AutoRABIT Vault, Spanning) and confirm the last full backup is recent (within 24 hours ideally). Run a fresh on-demand backup if the schedule is uncertain. Separately, take a Data Loader export of the affected custom object to S3, OneDrive, or any out-of-org archive. This belt-and-braces approach gives you two recovery paths if the Truncate turns out to be a mistake. Document the backup timestamp and the export file location in the Truncate runbook for audit.
- Validate the object has no Truncate blockers
Open Setup, Object Manager, find the custom object, and click Truncate. If the button is greyed out or returns an error on click, read the error message. Common blockers include analytic snapshots, Site references, managed package membership, and external ID dependencies. Resolve each blocker before proceeding: archive the analytic snapshot, decouple the Site, archive the managed package version. Re-test the Truncate eligibility after each fix. Do not push through a blocker by deleting downstream dependencies without coordinating; you may break unrelated features.
- Run the Truncate from Setup
With the backup confirmed, the export saved, and all blockers cleared, click the Truncate button in Setup, Object Manager. Salesforce shows a confirmation dialog with the warning that truncation is permanent and the data cannot be recovered through normal flows. Read the warning, type the object name into the confirmation field (if required), and click Truncate. The platform runs the truncation synchronously for small data sets and asynchronously for large ones. You receive an email when the job completes. Do not run other heavy operations on the same object while the Truncate is in flight.
- Validate post-Truncate state and downstream dependencies
After the Truncate completes, run a count query (SELECT COUNT() FROM Object__c) and confirm the result is zero. Walk through any downstream automation, reports, dashboards, or Lightning record pages that reference records on this object. Confirm they handle the empty state gracefully (no broken Lightning components, no missing field references in Apex). Validate that lookup relationships to the truncated object on other records have been cleared as expected. Update any documentation or runbooks that referenced records on this object, since those records no longer exist.
- Truncate is permanent and irreversible through standard Salesforce flows. The only recovery path is a backup tool. Confirm a recent backup exists before clicking Truncate; this is the single most important guardrail.
- Truncate does not fire per-record Apex triggers. If your audit logic depends on a trigger writing to a history object, you lose that audit trail. Use bulk delete with soft-delete instead when audit history matters.
- Standard objects cannot be truncated. Account, Contact, Opportunity, Lead, Case, and other standard objects have no Truncate button. The only way to empty a standard object is record-by-record delete or Data Loader bulk delete.
- Blocker errors are not always informative. If Truncate is greyed out without a clear reason, check analytic snapshots, Site references, managed package membership, and external ID dependencies. Salesforce documentation lists the full set.
- Lookup relationships to truncated records are broken silently. Parent records on the other side of a lookup are not deleted, but their reference to the truncated record becomes null. Audit downstream usage before the Truncate.
Trust & references
Straight from the source - Salesforce's reference material on Truncate.
- Truncate Custom ObjectsSalesforce Help
- Modify All Data PermissionSalesforce Help
- Data Loader GuideSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Truncate do?
Q2. Can truncation be undone?
Q3. When should you use it?
Discussion
Loading discussion…