Troubleshooting: Salesforce “Storage Limit Reached” – Identifying Data Hogs

Salesforce enforces distinct storage allocations across your organization for record data and physical files. When your organization reaches 100% of its data storage limit, users lose the ability to create new records, incoming API syncs stall, and standard business operations fail. Resolving this requires diagnosing the specific storage category involved, locating the objects consuming excessive space, and executing an archival or deletion strategy.

Fast Fix

Navigate to Setup > Storage Usage. Determine whether the bottleneck is Data Storage (records) or File Storage (files and attachments). Inspect the “Top Data Storage Consumers” list. Identify runaway objects—most commonly Task, EmailMessage, ContentVersion, or custom integration logs—and mass-delete or export and purge historical records using the Bulk API.

---

Diagnostic Snapshot

• Error Signatures: STORAGE_LIMIT_EXCEEDED, Your organization has reached its storage limit, Insufficient storage to complete operation.
• Storage Tiers: Data Storage (SObject database records) vs. File Storage (Attachments, Chatter files, Document objects, ContentVersion).
• Common Space Hogs: Automated email syncs (EmailMessage), CRM activity tracking (Task), integration debug logs, staging tables, and obsolete ContentVersion files.
• Permissions Required: System Administrator or “Modify All Data” permissions to view storage usage and delete records permanently.

---

Understanding the Salesforce Storage Model

Salesforce calculates storage differently depending on the data type:

1. Data Storage: Covers standard and custom database records. Almost all standard records (Accounts, Contacts, Leads, Opportunities, and Custom Objects) consume a flat 2 KB of storage per record, regardless of how many custom fields or text characters they contain.
   • Exceptions: Contact records consume 2 KB, but CampaignMember records consume 1 KB. Article types consume 4 KB.
2. File Storage: Covers raw binary data, including email attachments, Chatter uploads, Salesforce Files, Documents, and site assets. Space consumption matches the actual byte size of the uploaded files.

Because Data Storage is calculated on a per-record basis, an object with 500,000 empty custom records consumes roughly 1 GB of your data allocation.

---

Diagnostic Path: Pinpointing Runaway Objects

Storage Limit Reached Alert
 ├── Go to Setup ──► Storage Usage
 │    ├── Is Data Storage at 100%+?
 │    │    ├── Review "Top Data Storage Consumers" table
 │    │    ├── Check standard activity: Task / EmailMessage
 │    │    └── Check custom objects: Integration_Log__c, Staging__c
 │    └── Is File Storage at 100%+?
 │         ├── Review "Top File Storage Consumers" table
 │         └── Check ContentVersion, Attachment, and Document usage
 └── Check Storage Trend
      └── Are records multiplying daily? ──► Audit connected sync tools/bots

Step 1: Open the Storage Usage Dashboard

1. Log into your Salesforce org as an Administrator.
2. Go to Setup > enter Storage Usage in the Quick Find box.
3. Select Storage Usage.
4. Check the two summary bars at the top:
   • Data Storage: Displays total MB/GB used versus your licensed limit.
   • File Storage: Displays total file space used versus your licensed limit.

Step 2: Identify the Top Consumers

Scroll down to the Current Data Storage Usage table. The table displays every object in your org sorted by space consumed. Note the top 3 to 5 objects.

Look closely for these common data hogs:

• EmailMessage & Task: Automated inbox capture tools (like Einstein Activity Capture, Outlook Sync, or Gmail Integrations) can silently log millions of automated marketing emails, out-of-office replies, and calendar invites. If email loops are flooding the system, inspect your configuration with Fix: Salesforce “Email-to-Case” Loop – Preventing automated reply storms.
• Custom Logging / Error Objects: Third-party integrations, custom Apex logging frameworks, or ETL staging tables (e.g., Log__c, API_Transaction__c) often lack auto-purging logic, storing years of routine operational records.
• CaseHistory / FieldHistoryArchive: Aggressive field history tracking on high-velocity fields can generate massive row volume without providing actionable historical value.

---

Resolution Steps: Reclaiming Storage

Method 1: Mass Delete Stale Activity Records

If Task or EmailMessage objects consume the bulk of your storage:

1. Navigate to Setup > Mass Delete Records.
2. Select Mass Delete Tasks or run a SOQL deletion script using the Salesforce CLI or Data Loader.
3. Filter tasks by completion status and date: SELECT Id FROM Task WHERE Status = 'Completed' AND ActivityDate < LAST_N_YEARS:2
4. Export the IDs as a CSV backup, then perform a Delete operation using Data Loader.

Method 2: Hard-Purging Data via Bulk API

When you delete records through the standard UI or standard SOAP API, records are sent to the Salesforce Recycle Bin. Records in the Recycle Bin continue to count against your Data Storage limit.

To free up storage immediately:

1. Open Salesforce Data Loader.
2. Go to Settings and ensure Use Bulk API is enabled.
3. Select the Hard Delete operation.
   (Note: Hard Delete permanently purges records and requires the “Delete Activated Contract” or “Bulk API Hard Delete” user permission.)
4. Run the deletion file. Records bypass the Recycle Bin completely, and storage metrics update once platform indexing runs.

Method 3: Clean Up File Storage (ContentVersion)

If File Storage is full:

1. Run a query using Developer Console to find old, large attachments: SELECT Id, Title, ContentSize, CreatedDate FROM ContentVersion WHERE ContentSize > 5000000 ORDER BY ContentSize DESC LIMIT 1000
2. Identify orphaned files (files not linked to any active record via ContentDocumentLink).
3. Delete the parent ContentDocument records via Data Loader.

Method 4: Automated Pruning of Custom Log Objects

If custom objects are responsible for storage bloat:

• Deploy a scheduled Batch Apex job to delete logging records older than 30 or 60 days automatically:

public class PurgeOldLogsBatch implements Database.Batchable<sObject> {
    public Database.QueryLocator start(Database.BatchableContext bc) {
        Date threshold = Date.today().addDays(-30);
        return Database.getQueryLocator([SELECT Id FROM System_Log__c WHERE CreatedDate < :threshold]);
    }
    public void execute(Database.BatchableContext bc, List<System_Log__c> scope) {
        delete scope;
        Database.emptyRecycleBin(scope);
    }
    public void finish(Database.BatchableContext bc) {}
}

---

Long-Term Archival Strategies

If compliance or governance rules prevent permanent record deletion:

• Salesforce Big Objects: Migrate high-volume audit or transactional records into Big Objects. Big Objects are designed for billions of rows and do not consume standard Data Storage.
• External Object Storage: Move historical data to an external SQL database or cloud data lake, exposing it back to users in real time via Salesforce Connect. For diagnosing related connectivity issues, see Troubleshooting: Salesforce “External Object” Sync Failures (OData Errors).

---

Hard Stops and Operational Hazards

• Do not execute bulk deletions without an authenticated data backup. Always run an export job with all fields mapped before performing bulk deletes or hard deletes.
• If your production org is at 105%+ data capacity, incoming API updates from marketing automation, website leads, and ERP syncs will fail completely. If an immediate cleanup cannot be executed safely within minutes, contact your Salesforce Account Executive to purchase an emergency temporary storage increase while you finalize your data retention model.