July 6, 2023
Most Salesforce data problems get framed as quality problems. Cleaner records, fewer duplicates, better validation. Salesforce data management has a second half that almost nobody writes about. It is the one with a hard ceiling attached. That half is storage. Your org has a finite allocation, it fills quietly, and the day it runs out is the day imports start failing.
Here is how it usually surfaces. An integration has written a record per event for two years. Nobody checked the volume. Someone tries a routine data load on a Tuesday and it errors out. The admin opens Setup and finds the org near its limit. Now the choice is buying more storage today or deleting records nobody has authority to delete. Neither option is quick, and the load is still blocked.
This guide covers the operational half of data management. You will see what actually eats your allocation and how to read your own usage page. You will see how to decide what gets deleted, archived, or kept. You will also see how to stop the same squeeze happening again next year.
Salesforce splits storage into two separate pools. Confusing them is the most common mistake here. Data storage holds records. File storage holds attachments, uploaded files, and content.
They are allocated separately and they fill at different rates. An org can be comfortable on records while running out of file space, or the reverse. Fixing one does nothing for the other.
Both allocations depend on your edition and user count. Salesforce has changed the details over time. Check your own numbers rather than trusting a figure from a blog post, including this one. Setup shows you exactly what you have and what you have used.
The surprising part is that record storage has little to do with how much you typed. Most records are counted at a flat rate regardless of how many fields you filled in. An account with three fields populated and an account with eighty fields populated cost you close to the same.
That single fact changes where you should look. Field cleanup is good hygiene but it is not a storage strategy. Record volume is.
Run through that list for your own org before you assume the problem is dirty data. Usually one or two rows account for most of the growth.
Setup has a Storage Usage page. It shows your data and file allocations, how much is used, and a breakdown by record type. It is the most useful page in Salesforce that most admins open once a year.
The breakdown is what matters. It ranks your objects by record count and storage consumed, so the biggest contributor is visible in seconds. Administrator-focused guides on Salesforce Admins are worth reading alongside it.
First, percent of data storage used. Second, percent of file storage used. Third, your top three objects by consumption.
Write them down every quarter, in the same place. A single reading tells you where you are. Four readings tell you when you will run out, which is the number you actually need.
This is where most storage projects stall. Nobody wants to be the person who deleted the record that turns out to matter. So nothing gets deleted and the org keeps growing.
Stop asking whether data is useful. Ask who needs it, how quickly, and for how long. Those three answers put every record into one of three buckets.
Get a named owner to sign off each row before anything is deleted. A signed decision turns a risky judgment call into an agreed policy. It stops the same argument recurring every year.
Archiving keeps the data and moves it somewhere cheaper. That is right whenever a regulator, a contract, or finance needs the record to exist. Nobody needs it in a report.
Options run from exporting to external storage, through to keeping the data on the platform in a high-volume structure. The trade-off is always the same. Cheaper storage means slower and more limited access, so agree how the data will be retrieved before you move it.
The failure mode is archiving without a retrieval plan. Data you cannot get back on request is not archived, it is lost with extra steps.
A cleanup is a one-time win. Without a change to what writes records, the org refills at the same rate it did before.
Start with integrations, because they are the usual cause. Check what each connected system writes and how often. Check whether it creates a record or updates one. An integration logging every poll instead of every change can generate enormous volume for almost no value.
Then look at activity and history. Automatic task creation, email logging, and field history tracking all produce records nonstop. Each is useful somewhere and none of them needs to be on for every object.
Attachments are the file-side equivalent. A team that emails documents into Salesforce with every reply will duplicate the same file many times over. Community discussion on Forcetalks covers the patterns that cause this.
Every org accumulates records that belong to a process that no longer runs. A campaign from a product you retired. Objects from an integration you switched off. Records created by a user who left.
Orphaned data is the easiest storage to reclaim and the hardest to get permission for. By definition nobody is responsible for it. Someone has to be assigned.
Build a short list of objects with no active owner. Take it to whoever owns the budget. Framed as a storage cost with a name on it, these decisions get made fast. Framed as a data question, they sit for years. Learning material on SaaSGuru is useful background for the admins doing this work.
We start with a storage audit rather than a cleanup proposal. That means reading your usage breakdown and tracing the top objects back to the process creating them. Then we put a growth rate against each one.
From there we produce a retention decision for every major object. Each one carries a named owner. Nothing gets deleted until someone with authority has signed the row.
For data that must be kept, we design the archive with the retrieval path agreed up front. We also fix the source, because a cleanup without an integration change buys you about a year. Practitioner write-ups on Salesforce Ben cover the wider ecosystem view of these trade-offs.
Not immediately. Deleted records sit in the Recycle Bin before they are permanently removed, so plan for that lag in any cleanup.
Sometimes. If the data is genuinely needed and the growth is genuine, extra allocation is cheaper than the engineering time to avoid it. Decide it on the numbers, not on principle.
Duplicates cost storage and quality at the same time, so they are the easiest win. Our guide to Salesforce data cleansing covers the tooling and process.
It depends on volume and object type. Our comparison of Data Import Wizard and Data Loader sets out where each one fits.
The admin should report it and the business owner should decide retention. Our post on administration services for data and security covers how that split works day to day.
Clean data and sustainable data are two different projects. Record volume, not field completeness, fills your allocation. Start from the usage breakdown, not a cleanup wish list. Track the same three numbers every quarter and you will see the squeeze coming a year before it arrives.
Minuscule Technologies works on this from the engineering side. Our storage audit framework traces every high-volume object back to the process creating it and puts a growth rate against each. We then fix the source, not just the symptom, so the org does not refill at the same rate. And we tell you plainly when buying more storage is the cheaper answer.
Is your org creeping toward its limit, or already blocked by it? Bring it to Minuscule Technologies. We will read your usage breakdown and trace the growth to its source. You get a retention plan your team can approve. Wider platform work sits in our Salesforce consulting services.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
