What a Salesforce Data Retention Policy Should Cover Before You Hit Storage Limits

Salesforce storage problems usually appear late. An admin sees usage climbing as years of inactive CRM history compete with new records or a planned import. Act earlier, while the business can decide what stays live, what moves out of production, and what can be removed without breaking reporting or compliance duties.

A Salesforce data retention policy gives those decisions a written rule set. It should connect storage capacity to business purpose, legal requirements, record relationships, user access, and deletion controls. A cleanup reduces today’s volume. A policy explains what happens to new data as it ages, who approves each action, and how the team proves the rule worked.

This matters because Salesforce storage limits apply to different kinds of content in different ways. Records consume data storage. Files consume file storage. History data and archived activities follow separate rules. A useful policy has to account for these differences before Salesforce storage usage becomes an emergency.

TL;DR

A Salesforce data retention policy should define which records the business keeps, the event that starts each retention clock, how long data stays in production, when it moves to an archive, when it can be deleted, and which exceptions stop deletion. It should also separate record storage from file storage, protect record relationships, cover audit history and legal holds, assign owners, test restore or retrieval, and track storage growth over time. The goal is predictable Salesforce storage management before capacity pressure forces rushed deletion.

·  Start with actual storage consumption by object and file type.

·  Give each record class a clear retention clock and final action.

·  Separate live data, archived data, and records approved for deletion.

·  Treat files and audit history as their own policy areas.

·  Review the policy against storage trends, legal changes, and business use.

Why The Policy Must Come Before The Storage Problem

A retention policy works best when it is written before the org is close to its limit. Salesforce provides a current view of data and file consumption in the Storage Usage page, including the total limit, current use, and the main components consuming storage. That page is useful for a snapshot, but Salesforce notes that it does not provide standard historical tracking of storage use. Teams that wait for a high percentage therefore have less evidence about how quickly the org is growing and which object caused the change.

That gap is why Salesforce storage management should be treated as an operating process rather than a cleanup project. A team needs enough time to identify owners, check integrations, trace object relationships, decide whether data still has business value, and confirm whether a law or contract requires retention. Rushed cleanup often begins with the largest objects, yet the largest object is not always the safest one to remove.

The policy also creates a boundary between capacity decisions and records decisions. Salesforce storage limits are technical limits, while retention periods are business and legal decisions. One should inform the other, but storage pressure should not invent a retention period. A closed case might be inactive and still need to remain accessible for a contractual period. An old lead might have little operational value and still contain personal information that should not remain indefinitely.

A mature retention policy therefore answers 2 questions at the same time: how much data can remain in production, and how long each category should exist anywhere in the retention chain. That makes Salesforce storage management more predictable and gives admins a defensible basis for archiving or deletion.

What Salesforce Storage Actually Counts

Salesforce separates data storage from file storage, so the first policy decision is to measure them independently. The current storage allocation table lists a 10 GB minimum data allocation for many paid editions, with per-user additions that vary by edition. File storage also has edition-specific allocations. Because contracts and license mixes differ, the policy should point admins to the org’s Company Information and Storage Usage pages instead of hard-coding a capacity number that may become wrong later.

Most common CRM records consume data storage, while uploaded files consume their actual file size. Salesforce’s current file storage guidance lists content, documents, attachments, and related components that contribute to file use. This means a retention rule for old Cases may have 2 storage effects: the Case records affect data storage, while the files attached to those cases can affect file storage much more heavily.

Record counts alone can also mislead. Salesforce publishes record size estimates showing that many standard records are roughly 2 KB, while some record types and content patterns can use more. Rich text and related records can increase the footprint around a business process. A policy should therefore pair record counts with the storage breakdown and, where needed, exported data that shows which objects and file relationships are driving growth.

Build A Data Inventory Before Setting Retention Periods

The policy should begin with an inventory of the data that exists, who uses it, and why it is kept. A simple object list is not enough. The same object can contain record types with very different value. For example, an open opportunity has an active sales purpose, while a closed-lost opportunity from several years ago may be needed only for analysis. A Contact may still support an active account relationship even when the contact record itself has not changed recently.

For each object or record class, capture the business owner, system owner, sensitivity, volume, date field that can drive retention, key child objects, reporting use, integration use, and legal basis for keeping the data. This inventory gives the policy enough context to define rules without using age as the only test. It also helps expose custom objects that quietly grow because an integration keeps inserting records after users stop looking at them.

The storage view should be part of the inventory. Record the current storage figures for the largest data objects and the main file categories, then save that snapshot outside Salesforce if trend reporting is needed. Repeating the snapshot monthly creates a basic growth history that the standard Storage Usage page does not supply. The policy can then set review triggers based on growth rate as well as the current percentage used.

Define A Retention Schedule That Can Be Executed

A retention schedule turns policy language into rules an admin can test. Each row should name the record class, the event that starts the clock, the period, the action at expiry, the owner, and any exception. A vague line such as “keep Cases for 5 years” leaves too much unresolved. The clock might start at creation, closure, last activity, contract end, or another business event, and those choices can produce very different record sets.

A useful schedule can look like this:

The exact periods must come from the organization’s obligations and purpose for keeping the data. Privacy guidance supports that approach. The UK ICO’s storage limitation guidance says organizations should justify how long personal data is kept, document standard periods where possible, and erase or anonymize data when it is no longer needed. The Salesforce data retention policy should therefore avoid one period for every object unless the business can explain why that period fits every record in the set.

The schedule should also distinguish minimum retention from maximum retention. A tax, contract, or dispute requirement may create a minimum period. Privacy rules or internal risk controls may create a reason to remove data once the purpose ends. CRM data retention works better when both boundaries are visible, because “keep at least 7 years” is different from “keep exactly 7 years and then review.”

Decide What Stays Live, What Gets Archived, And What Gets Deleted

Every rule needs an end state. The common choices are to keep the data live, move it to an archive, delete it, or anonymize selected personal fields. The decision should be based on access need and retention purpose. Live Salesforce is appropriate for records that support current workflows or frequent reporting. An archive fits information that must remain available but is rarely used. Deletion fits data with no remaining business or legal purpose.

Salesforce data archiving should be used when the organization still needs the record but does not need it in day-to-day production. Salesforce’s archive policy setup supports criteria-based policies and retention periods for archived records. The product can also account for relationships when a hierarchy is selected, which matters because a parent record and its children often need to move together. The tool choice can vary, but the policy principle stays the same: archive because the data still has a purpose, not because “old” automatically means “archive.”

A backup serves a different purpose. Salesforce’s data export guidance describes scheduled or manual exports that create CSV copies of org data. Those copies can support recovery or offline retention, but a backup does not by itself define which records users should keep in production or when a record should be destroyed. The retention policy should name backup requirements separately so recovery copies do not become an unmanaged permanent archive.

This decision model makes archiving part of the full lifecycle instead of a storage shortcut. It also prevents Salesforce storage limits from pushing teams toward permanent deletion when retrieval is still required.

Write Object-Specific Rules And Protect Record Relationships

Retention rules become risky when they ignore Salesforce relationships. Deleting an Account can affect Contacts, Opportunities, Cases, custom children, files, sharing records, and external systems that keep the Salesforce ID. Archiving a parent without its related detail can make the retained record incomplete. A sound retention policy therefore includes dependency checks before any bulk action.

Start with the objects that dominate storage consumption, then map upstream and downstream dependencies. Review master-detail relationships, required lookups, junction objects, roll-up logic, flows, Apex, scheduled jobs, and integrations that query the candidate records. The goal is to understand what expects the record to exist and what should happen after it moves or disappears.

Activities need special treatment because Salesforce already archives some older Tasks and Events. The archived activity rules explain that certain events and closed tasks are archived after they reach the age criteria, and archived activities require different query behavior through the API. They also may not appear in standard reports. A retention project that counts visible activities without understanding this behavior can understate the history that still exists.

Object rules should also define the deletion order. Child records may need to move or be removed before a parent. External references may need a retained key or archive locator. Reports may need a replacement dataset after archiving. This is where CRM data retention becomes an architecture task rather than a filter on CreatedDate.

A practical rule should be precise enough to test. “Archive old opportunities” is weak. “Archive closed opportunities 36 months after CloseDate when there is no open renewal record and preserve the account reference” gives an admin a measurable population and an exception. The final period is only an example; the business must set the real period from its own requirements.

Treat Files And Attachments As A Separate Retention Problem

Files often become the hidden storage problem because their size varies far more than CRM rows. A Case with a few text fields may be small, while its screenshots, PDFs, email attachments, and multiple file versions can consume much more. The Salesforce data retention policy should therefore set file rules independently from the parent record’s data rule.

For each major file source, define whether the file must remain with the parent, can move to an archive, can be moved to an external repository, or should be deleted earlier than the record. The policy should also account for duplicate uploads and old versions where business rules allow removal. Current component usage should be checked before deciding which file group deserves attention.

File retention also needs an access rule. If a closed case is archived but its attachments stay in production, the team has reduced only part of the footprint. If the attachments move elsewhere, users need a way to retrieve them when a dispute or audit requires evidence. The archive must preserve enough metadata to connect the file to the correct account, case, contract, or other business record.

Preserve Audit History Without Keeping Every Business Record Live

Audit history and business records should not be treated as the same retention set. Salesforce Field History Tracking has its own behavior. The official field history guidance says standard field history is retained for up to 18 months in Salesforce and up to 24 months through the API when Field Audit Trail is not enabled. It also states that field history tracking data does not count against data storage limits.

Organizations that need longer field-level history can use Field Audit Trail where licensed. Salesforce’s Field Audit Trail documentation says archived field history can be kept until it is manually deleted, and retention policies can be defined for supported objects. This can let a team preserve evidence of key field changes without keeping an otherwise inactive operational record live solely because someone might need the change history later.

The Salesforce data retention policy should specify which fields need history and why. Tracking every possible field can make audits harder to interpret even when it does not consume standard data storage. Focus on fields that carry approval status, financial meaning, ownership changes, consent state, or other evidence the organization has a reason to preserve. Custom audit objects need their own review because they can consume normal Salesforce storage.

This distinction can materially change Salesforce storage management. If the business says it needs a 7-year audit trail, ask whether it needs the full live record for 7 years or whether an archive plus the required history is enough. That question often produces a safer rule than keeping every record searchable in production indefinitely.

Put Privacy Rules, Legal Holds, And Deletion Rights Into The Policy

Salesforce storage limits cannot override a legal hold, and a general retention period cannot override a valid deletion duty without review. The policy needs an exception process that pauses deletion when litigation, investigation, audit, or another approved hold applies. The hold should identify the records in scope, the owner, the start date, and the event that releases the hold. That creates a clear control when a scheduled purge would otherwise remove the data.

Privacy rules also affect CRM data retention. The California Privacy Protection Agency explains in its CCPA privacy guidance that collection, use, and retention of personal information must be reasonably necessary and proportionate to the disclosed purpose, and consumers have deletion rights subject to exceptions. The policy should map those requirements to Salesforce objects rather than treating privacy requests as a separate manual process with no link to normal retention.

The same principle appears in US security guidance. The FTC’s retention policy guidance advises businesses to keep sensitive personal information only as long as there is a legitimate need and to use a written records retention policy that covers how long information is kept and how it is disposed of. This supports a core design rule: a Salesforce data retention policy should explain why data remains, not merely how much storage is available.

Salesforce Privacy Center can support some of these workflows where licensed. Its retention policy controls can copy customer data to a retention store and can apply anonymization or deletion actions. The policy should still define the business rule first. Product settings are implementation details, while the written rule determines which records qualify and what evidence the organization keeps about the action.

Turn The Policy Into Repeatable Automation And Controls

A policy that depends on an admin running ad hoc filters every few months will drift. Repeatable Salesforce data lifecycle work needs scheduled review, controlled execution, and evidence. Automation can flag candidates, archive approved records, anonymize fields, or delete records after the right approvals. The exact method depends on volume, licensing, relationships, and the need to restore data later.

Start by separating selection from destruction. A scheduled job can produce a candidate list first. Business or legal owners can review exceptions. The final action can run only after approval. This separation is especially useful for the first cycles of a new Salesforce data retention policy because it exposes filters that are too broad before records are permanently changed.

Deletion behavior must also be understood. Salesforce’s Recycle Bin guidance confirms that records in the Recycle Bin do not count against org storage usage, even though they remain recoverable for a period before permanent removal. That means a standard delete can relieve Salesforce storage usage without immediately removing the recovery option. The policy should still define when permanent deletion is appropriate, who can perform it, and what evidence is retained.

Automation should log the policy version, run date, filter criteria, counts selected, counts processed, exceptions, failures, and approver. Those logs make Salesforce storage management easier to audit and troubleshoot. They also help explain why record totals changed between reporting periods.

A mature Salesforce data lifecycle process also includes failure handling. If an archive job partially fails, the team needs a rerun rule that does not duplicate archived records. If a delete is blocked by a relationship, the exception should be visible. If an integration recreates deleted records, the policy should route that problem back to the source process rather than repeatedly deleting the same data.

Use A Pre-Deletion And Pre-Archive Checklist

The safest retention job has a repeatable gate before records move or disappear. The checklist should be short enough to use every time and detailed enough to catch the failures that create reporting gaps or broken integrations.

·  Confirm the policy rule, policy version, and approving owner.

·  Recount the candidate population and compare it with the previous estimate.

·  Sample records across record types, regions, and business units where those differences affect the rule.

·  Check legal holds, open disputes, active contracts, and privacy exceptions.

·  Trace parent-child relationships and any required deletion or archive order.

·  Review reports, flows, Apex, and integrations that reference the records.

·  Confirm the archive destination, retention period, access permissions, and retrieval method when archiving applies.

·  Confirm backup or recovery coverage before irreversible deletion where the recovery policy requires it.

·  Record the current storage figures so the effect can be measured after the run.

·  Run a limited batch first and verify counts, relationships, user access, and expected storage change.

This checklist keeps Salesforce data archiving tied to the approved retention rule. It also prevents a common mistake: proving that records can be removed technically without proving that the business can still operate after they are gone. Salesforce storage management depends on both tests.

Test Retrieval, Reporting, And Recovery Before Full Rollout

A retention rule is incomplete until the team tests what happens after execution. In a sandbox or controlled sample, archive records using the same relationship rules planned for production. Then test the user path for retrieval. If a support manager needs a 5-year-old closed case during a dispute, the policy should say how that manager gets the record, who can authorize access, and how long retrieval should take.

Reporting deserves a separate test. Dashboards that once queried 8 years of opportunities may change after Salesforce data archiving removes older records from production. The business may accept that change, may need an external reporting store, or may need summarized historical metrics retained in Salesforce. The policy should identify this before the first large archive run so a storage project does not silently alter executive reporting.

Recovery tests matter for deletion too. If policy allows a recovery window, verify that the chosen backup or export process can restore the record and its important relationships. A CSV copy can preserve values while still requiring work to rebuild relationships, files, or automation context. The Salesforce data retention policy should describe the recovery expectation in business terms so the technical method can be judged against it.

Testing should also compare expected and actual storage figures. If the job removes 2 million records but the storage reduction is far smaller than forecast, investigate record type assumptions, related records, or file storage before running the next batch. Salesforce storage limits should be managed with measured results rather than record-count guesses.

Monitor Storage Growth And Review The Policy On A Schedule

Track Salesforce storage usage on a regular cadence, with separate figures for data and file storage. Capture the largest objects, major file categories, percentage used, monthly growth, and any large one-time imports. A simple external history is useful because Salesforce’s standard Storage Usage view is a current snapshot rather than a full trend line. The team can use that history to forecast when a policy action must run instead of reacting at the limit.

The policy should define an internal trigger that leaves time for analysis. The exact percentage depends on growth rate, data criticality, planned migrations, and procurement lead time. Salesforce guidance for its Archive app discusses acting before storage is full, and that principle is sound even when another archive method is used. A fast-growing org needs a larger buffer than a stable org because a monthly review can miss a sudden import or file spike.

Review the Salesforce data retention policy at least when a major system change occurs and on the governance cadence the organization has approved. The review should test whether periods still match purpose, whether owners are current, whether archive retrieval still works, and whether deletion evidence is complete. CRM data retention rules that were reasonable 2 years ago may no longer fit a redesigned sales or service process.

A useful metric is net storage growth after retention actions. If Salesforce data archiving removes 10 GB each quarter while new processes add 14 GB, the policy is working as designed but capacity is still shrinking. That points to collection controls, file behavior, or architecture changes rather than simply running the archive job more often.

A Practical Salesforce Retention Operating Model

The operating model should make ownership clear. The Salesforce platform owner maintains the technical rules and storage trend. Business owners approve whether historical records still have operational value. Privacy or legal teams define restrictions, hold requirements, and approved retention periods where required. Security or records teams may control archive access and deletion evidence. Each policy row should have one accountable owner even when several groups contribute.

Run the model as a cycle. Measure current storage, identify the next policy population, review exceptions, execute the approved action, validate retrieval or deletion, and record the capacity change. The process can be monthly for fast-growing orgs or less frequent for stable environments, but the schedule should be explicit. This gives Salesforce storage management a predictable rhythm without turning every review into a new design exercise.

The same model should cover changes to the policy itself. A new retention period should have an effective date, approver, affected objects, and treatment for records already archived. If a shorter period is adopted, the team must decide whether it applies to existing data or only new data. If a longer period is required, the organization needs to know whether older records still exist and whether prior deletions were final.

Common failures are easy to spot: one age rule for every object, archives with no expiry date, file growth ignored, parent records removed before dependencies are checked, and jobs run without before-and-after evidence. The operating model should catch these failures during review rather than after users report missing data.

The final test is simple: another qualified admin should be able to read the Salesforce data retention policy and understand which records qualify, what happens to them, who can stop the action, and how success is checked. If those answers live only in the original admin’s memory, the policy is not operational yet.

Conclusion

A Salesforce data retention policy should be written as a lifecycle control, not as an emergency response to low capacity. It needs a storage baseline, a record inventory, a defensible retention schedule, clear outcomes for live data and archives, file rules, relationship checks, audit-history treatment, privacy exceptions, legal holds, execution controls, and evidence that each run worked. Those pieces let the organization manage Salesforce storage limits without making deletion decisions under pressure.

The strongest policy also separates technical capacity from the reason data exists. Salesforce data archiving can reduce production volume, and deletion can reduce retained data, but neither action should happen without a stated purpose and an owner. When Salesforce storage usage is tracked over time and CRM data retention rules are reviewed on a schedule, storage becomes a planned part of platform governance rather than a surprise.

FAQs

What Should A Salesforce Data Retention Policy Cover?

A Salesforce data retention policy should define data classes, retention clocks, retention periods, end actions, owners, exceptions, legal holds, archive access, deletion evidence, and review cadence. It should also separate data storage from file storage and explain how relationships are handled before records move or disappear.

How Often Should A Salesforce Data Retention Policy Be Reviewed?

Review it on the governance schedule approved by the organization and whenever a major Salesforce, legal, privacy, or business-process change affects stored data. Fast-growing orgs may review storage monthly while reviewing the written policy on a slower cadence. The key is to make both reviews scheduled rather than reactive.

When Should We Act Before Reaching Salesforce Storage Limits?

Set an internal trigger that leaves enough time to analyze objects, test archive or deletion rules, and obtain approvals. The right threshold depends on growth rate and planned imports. A fast-growing org needs more headroom than an org whose storage changes slowly.

What Is The Difference Between Retention And Archiving In Salesforce?

Retention defines how long information should exist and what happens when that period ends. Salesforce data archiving is one possible action within that lifecycle. Archived records remain available under controlled access while leaving normal production storage or workflows, depending on the archive design.

Does Salesforce Data Archiving Replace Backup?

No. An archive is designed for selected historical records that still need long-term access. A backup is designed for recovery after loss, corruption, or an unwanted change. The policy should define both because they solve different problems.

Do Deleted Records In The Recycle Bin Count Against Salesforce Storage Usage?

Salesforce states that records in the Recycle Bin do not count against org storage usage. They remain recoverable for a period before permanent removal. A retention policy should still define when permanent deletion is allowed and who can approve it.

Should Files Use The Same Retention Period As Their Parent Records?

Only when the business and legal reasons are the same. A file may need to be kept longer than its parent record, or it may be disposable earlier. File size can also make it a larger contributor to capacity, so file rules should be explicit.

Which Salesforce Objects Should Be Reviewed First?

Start with the objects and file categories that drive the largest share of Salesforce storage usage, then check business value and dependencies before acting. Large volume alone does not make an object safe to archive or delete. Parent-child relationships and integration use can change the decision.

Can We Use CreatedDate As The Retention Clock For Every Object?

Usually no. The meaningful clock may be CloseDate, ClosedDate, contract end, last activity, consent expiry, or another event tied to the reason the record exists. The chosen field should match the business or legal rule behind the period.

How Does Field History Affect Salesforce Storage Management?

Standard field history follows Salesforce-specific retention behavior and does not count against normal data storage. Field Audit Trail can support longer history where licensed. Custom audit objects are different and may consume normal storage, so they need their own rule.

What Happens If A Record Is Under Legal Hold?

A legal hold should pause normal deletion or purge for the records in scope until the authorized owner releases the hold. The policy should document how holds are identified, who owns them, and how scheduled jobs exclude held records.

Should Archived Data Have Its Own Deletion Date?

Yes. Salesforce data archiving should not become indefinite storage by default. The archive policy should define how long records remain there and what happens at expiry, subject to legal holds or other approved exceptions.

How Can We Forecast When Storage Will Become A Problem?

Save regular Salesforce storage usage snapshots outside the standard current-state page and calculate net monthly growth. Add planned migrations or large imports, then subtract expected archive or deletion effects. The forecast does not need to be complex to be useful.

How Do We Prove A Retention Job Worked?

Keep the policy version, candidate count, approval, run date, processed count, failures, exception list, and before-and-after storage figures. For archives, also test retrieval. For deletion, keep the evidence required by the organization’s governance process.

Is CRM Data Retention Mainly An Admin Responsibility?

No. Admins implement much of the technical work, but CRM data retention depends on business purpose, privacy requirements, legal holds, security controls, and records ownership. The policy should assign accountable owners so technical staff are not making legal or business retention decisions alone.