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.