Archive Salesforce data when old records still matter for audits or history but no longer help anyone do daily work. Purge data that no rule or person needs anymore. Both lower storage use, and both make big objects quicker to query and report on. The order matters, though. Write a retention policy first, then sort each object into keep, archive or delete, then choose tooling. Picking a tool before the policy usually means archiving the wrong things.
Why does old data become a Salesforce problem?
Old data costs you in two places: storage capacity and the speed of everything that scans large tables. Neither shows up on day one, which is why archiving tends to start as an emergency.
An org that has run for years piles up closed cases, logged emails, completed tasks, abandoned leads and integration logs. Users rarely open them. Yet every list view, report and search still has to work around them, and every new record competes for the same storage allocation. Archiving is the routine that stops the backlog from growing faster than the business does.
How do data storage and file storage limits differ?
Salesforce meters records and files separately. Data storage covers rows in standard and custom objects, while file storage covers attachments, Salesforce Files, documents and similar binary content.
Salesforce documents a base data allocation per org plus a small amount added for each user license, and a separate file allocation. Most record types count as a flat size each, regardless of how many fields they fill. That means a million tiny task records can weigh more than a few large PDFs. Allocations and the price of extra capacity vary by edition and contract. Confirm your figures with your Salesforce account team before you plan around them.
Check Storage Usage in Setup to see which objects consume the most space. The top few objects usually account for most of the total, and that list tells you where an archive policy will pay off first.
Does archiving actually make Salesforce faster?
It often helps reports, list views and searches that scan large objects, because fewer rows means less work per query. It will not fix slow pages caused by heavy layouts, chatty automation or poor sharing design.
Large data volumes slow down queries that cannot use a selective filter. A report on all open cases may be quick, while a report filtered on an unindexed field across ten years of cases can time out. Moving inactive rows out of the object shrinks the table those queries must scan. Sharing recalculation and full sandbox refreshes also get lighter. If your users complain about slowness generally, diagnose the cause before assuming volume is to blame; our guide on why Salesforce is slow covers that triage.
Who should set the retention rules?
Legal, compliance and records management set how long data must be kept; the business decides how long it is useful. Admins and architects turn those decisions into object-level rules and automation.
Retention periods come from contracts, industry regulation, tax rules, privacy law and litigation holds. Each one pulls in a different direction. Some say keep records for a minimum period, while privacy rules may say remove personal data once its purpose has ended. This article offers design guidance, not legal advice. Get the actual periods in writing from your counsel or compliance lead, then document them per object.
A useful policy answers four questions for every object. How long must it be kept? How long do users need it inside Salesforce? What event starts the clock, such as case closure or last activity? And who can approve an exception, such as a legal hold?
Which records should we keep, archive or delete?
Keep what users touch, archive what you must retain but rarely read, and delete what has neither a business nor a legal reason to exist. Most orgs find a handful of objects drive most of the decision.
- Closed cases: usually archived after a set period from closure, with case number and summary fields kept searchable for agents handling repeat customers.
- Completed tasks and logged emails: high in count, low in value once old. Archive or delete them, but keep recent history on active accounts.
- Inactive leads: leads with no activity and no consent to market are candidates for deletion, which also supports privacy obligations.
- Field history: standard tracking ages out on its own schedule, so decide whether you need longer audit history before it disappears.
- Integration and debug logs, staging records and error rows: rarely needed beyond a short window and often the easiest storage win.
- Files and attachments: old contract scans and email attachments can move to file archives while the parent record stays.
What retention schedule fits common Salesforce objects?
Start from a table like the one below and replace the drivers with your own approved periods. The options column shows where each object typically lands, not a rule.
| Object | Typical retention driver | Usual options |
|---|---|---|
| Closed cases | Service quality reviews, contract terms, sector regulation | Keep recent in org; archive older with lookup from the account |
| Tasks and events | Account context for sellers and service agents | Keep recent; archive or delete older completed activity |
| Logged emails | Customer correspondence obligations, disputes | Archive with attachments; delete low-value automated notices |
| Leads with no activity | Privacy law, marketing consent | Delete or anonymize after an agreed inactive period |
| Closed opportunities | Revenue reporting, forecasting trends, audit | Usually keep; summarize very old years if volume is extreme |
| Field history | Audit and change tracking needs | Accept standard retention, add Field Audit Trail or export history |
| Integration logs and staging rows | Troubleshooting only | Delete on a short rolling schedule |
| Files and attachments | Contracts, signed documents, evidence | Move older files to archive storage; keep the reference on the record |
What native Salesforce options exist for archiving?
Salesforce offers big objects for storing very large datasets on the platform, and a separate archiving product. Product names and packaging have shifted, so verify current options before committing.
Big objects hold massive record counts with consistent query performance, and they do not consume standard data storage in the same way. The tradeoff is real. You query them by a defined index, they support limited reporting, and Salesforce notes big objects do not support encryption. Archived encrypted fields would land as clear text, which may rule them out for sensitive data.
Salesforce also sells an archiving product, currently marketed as Salesforce Archive. Its help documentation lists a newer Archive app, a managed package version and a legacy Salesforce Archive. Salesforce describes policy-driven offloading of records and files, search from within related records, restore to production and freezing records under litigation hold. Edition requirements, storage location and pricing are contract details, so confirm them with your account team.
Can archived data live outside Salesforce and still be viewable?
Yes. A common pattern copies old records to a data warehouse or archive database, deletes them from the org, and surfaces them on demand inside Salesforce.
Salesforce Connect is the usual native route for that last step. It presents outside data as external objects, so users can see an archived case list from an account page without the rows counting against storage. It typically requires an add-on license, and external objects behave differently in reports and automation. A lighter alternative is a simple lookup screen or link to the warehouse for the rare user who needs history.
Whatever you choose, test the restore path. An archive nobody can read back, or that loses the link between a case and its account, is closer to deletion than archiving.
Which AgentExchange (formerly AppExchange) tools are worth evaluating?
AgentExchange tools fall into a few categories, and the right one depends on whether you need storage relief, compliance features or analytics on history.
- Archive platforms that move records and files to external storage with policies, search and restore.
- File offload tools that relocate attachments to cloud storage and keep a link on the record.
- Backup products that also offer archive features, which can reduce vendor count.
- Data management utilities for bulk deletes, mass updates and scheduled cleanups run by admins.
Ask each vendor where data is stored, how it is encrypted, how restore preserves relationships, and how retention and legal hold are enforced.
Is a backup the same as an archive?
No. A backup is a recovery copy of current data for when something breaks. An archive is the long-term home for data deliberately moved out of daily use.
Backups protect you from bad imports, faulty automation and accidental deletes, and you restore from them to get back to a known state. Archives answer retention and storage needs, and you search them for individual records. Salesforce sells Backup and Recover, which came from its acquisition of Own Company, as a separate product from Archive. Having one does not cover the other, so plan both.
How does deletion work, and what can go wrong?
Deleted records normally sit in the Recycle Bin for a limited period before permanent removal. Bulk API hard delete skips that step, so treat it as irreversible.
Salesforce documents a fifteen-day Recycle Bin window, after which records are queued for permanent deletion. Hard delete through the Bulk API requires a dedicated permission and leaves no undo. Before any large purge, check these mechanics.
- Cascade effects: deleting a parent in a master-detail relationship deletes its children, and some standard objects remove related records too.
- Record locks: mass deletes of child records can lock the shared parent, so batch by parent and run outside busy hours.
- Automation: triggers and flows on delete may fire thousands of times, so pause or bypass them deliberately.
- Integrations: downstream systems may resync or flag missing records, so tell their owners first.
- Reporting: historical dashboards can shift once old rows disappear, so snapshot key figures before purging.
What mistakes do teams make with archiving?
The common errors come from rushing to free storage without a policy or a test. Each one is avoidable with a little planning.
- Buying a tool before legal and compliance agree on retention periods.
- Archiving children but leaving orphaned references, so users see broken links.
- Deleting leads or contacts that still hold valid marketing consent records.
- Treating a backup subscription as the archive, or the reverse.
- Running a one-time purge and never scheduling the next one.
- Ignoring file storage while chasing record counts.
If storage alerts or slow reports are the trigger, our optimization team can size the problem. We can then design a schedule your counsel can approve. Pair it with duplicate cleanup so you are not archiving records that should simply be merged.
