What Is the Salesforce Recycle Bin and Why Does It Exist?
If you work in Salesforce long enough, you’ll eventually delete something you didn’t mean to. Sometimes it’s a single record. Sometimes it’s thousands. Either way, that moment of “we need that back” happens more often than most teams would like to admit.
The Salesforce Recycle Bin exists to soften that blow. It acts as a temporary holding area for deleted records, giving users a short window to reverse mistakes without escalating into a full recovery effort. For day-to-day operations, it’s a useful safety net, helpful enough that teams often assume it covers more than it does. Understanding what the Recycle Bin actually is, and what it isn’t, matters more than most people realize until they need it.
My Recycle Bin vs Org Recycle Bin: Who Can See Deleted Items?
Salesforce separates deleted records into two views, and that distinction matters a lot more than people realize.
“My Recycle Bin” shows records you personally deleted. It’s useful for quickly undoing your own mistakes, especially on smaller teams where users manage their own data.
The “Org Recycle Bin” is different. It gives admins a centralized view of all deleted records across the organization, essential for troubleshooting, auditing, and recovering data that someone else deleted. In larger environments, most recovery efforts happen here. Data ownership is distributed, and issues rarely stay contained to one user.
Which Objects, Records, and Metadata are Supported?
Standard and custom object records are both supported, including Accounts, Contacts, Opportunities, and custom objects your org has built out for specific business purposes. Attachments and Documents typically come along too, which helps preserve context for whatever was deleted.
What doesn’t always come back cleanly is the metadata and relationships surrounding those records. In a simple environment that rarely matters. In a complex one, it matters a lot. You can end up with records that technically exist again but aren’t connected to anything they’re supposed to be connected to, which creates a different kind of problem than the one you started with.
Salesforce Recycle Bin Times & Storage Limits
Reliability usually comes down to two things: time and storage.
By default, deleted records are retained for 15 days. Salesforce Classic offers the option to extend this to 30 days. That sounds reasonable until you consider how often data issues aren’t caught until well after that window has closed.
Storage limits add another layer of risk. The Recycle Bin’s capacity scales with your org’s overall data storage, roughly 25x your allocation, though Salesforce doesn’t define this cleanly in their documentation. When that limit is reached, Salesforce automatically purges the oldest records to make room for new ones. No alert. No warning. Records you expected to have for 15 days may only last a few if deletion volume is high. In high-traffic environments, that’s not an edge case. It’s routine.
Outgrow The 15-Day Recycle Bin Limit
Protect your Salesforce data with retention that works on your timeline, not Salesforce’s.
How Does Record Deletion Work In Salesforce?
Deleting data in Salesforce isn’t a single event. It’s a process with multiple paths depending on how the deletion occurs.
What happens when a user deletes a record from the UI?
When a user deletes a record through the Salesforce interface, the system performs a soft delete. The record moves into the Recycle Bin and disappears from reports, dashboards, and standard workflows, but it still exists behind the scenes and can be restored without a complex recovery process.
For most everyday mistakes, this works fine.
How do Apex and API deletes interact with the Recycle Bin?
Deletes performed through Apex or APIs generally follow the same soft delete behavior. Records go to the Recycle Bin and can be recovered within the retention window.
The important nuance: bulk operations and certain API configurations can trigger hard deletes, bypassing the Recycle Bin entirely. This is often intentional, done for performance or data management reasons, but it removes any possibility of native recovery. In environments with integrations or automated processes, large volumes of data can be deleted this way without anyone noticing immediately.
Salesforce Hard Delete vs Soft Delete
A soft delete gives you a buffer. The record is recoverable for a limited time, and in most cases, the issue gets resolved quickly.
A hard delete is permanent. The record is gone from Salesforce, the Recycle Bin doesn’t apply, and your only option is an external backup if one exists. Knowing which type of deletion is happening, and who can trigger it, is the difference between a five-minute fix and a crisis. If you’re running bulk operations through an integration, assume hard deletes are happening unless you’ve confirmed otherwise.
Where Are Deleted Records Stored, and For How Long?
Deleted records don’t vanish immediately. They move into a system-managed layer that sits outside your active dataset. It’s designed to support recovery without touching your primary storage. The catch is that this layer has its own constraints, and they’re easy to overlook until you’re in the middle of a recovery effort trying to find something that should still be there.
What Is the Maximum Capacity of the Salesforce Recycle Bin?
Salesforce doesn’t publish a clean number here. The widely accepted figure is roughly 25x your total data storage allocation, but you won’t find that spelled out clearly in official documentation. For most orgs it’s enough headroom, until there’s a bulk operation, a cleanup project, or a period of unusually high deletion activity. Then it fills faster than anyone expects.
Automatic Purging: What Happens When the Recycle Bin Is Full?
No alert. No warning. When capacity is reached, Salesforce quietly starts removing the oldest records to make room for new ones. That 15-day window you’re counting on might be three days in practice. Teams that treat the Recycle Bin as a reliable safety net often find this out at the worst possible time.
Salesforce Unlimited Edition vs Enterprise Edition: differences in capacity
Enterprise Edition starts with limited storage, around 10 GB plus per-user allocation, so the Recycle Bin fills faster, particularly in active environments with frequent updates or bulk changes.
Unlimited Edition comes with significantly more storage, which gives the Recycle Bin more room and makes automatic purging less of an immediate concern. Same underlying rules either way. Hit the limit in either edition and older records go, full stop.
Extended Recycle Bin retention: Can I Increase the Time Limit?
Yes, with a caveat that matters a lot depending on how your org is set up.
Salesforce Classic admins can enable Extended Recycle Bin Retention to stretch the window from 15 days to 30. Useful if your team tends to catch data issues slowly. But this feature doesn’t exist in Lightning Experience. Most modern Salesforce environments run Lightning. And even in Classic, the extended window doesn’t override storage limits. Fill the bin and records still get purged early, regardless of the time setting. It buys time in the right circumstances. It’s not a fix.
How can users find and restore deleted records?
Recovery looks straightforward at first. The complexity comes quickly once you’re dealing with volume or interconnected records.
Accessing the Recycle Bin in Salesforce Classic and Lightning
In Lightning, open the App Launcher, search for “Recycle Bin,” and you’ll get a dedicated view where deleted records can be filtered and restored. In Classic, the Recycle Bin lives in the sidebar, more immediately visible for users familiar with the older interface.
Once inside, you can filter by object type, deletion date, or ownership. The interface is simple enough for individual record recovery, but it gets harder to navigate when deletion volumes are high and you’re searching for something specific.
Steps to Restore a Single Record Through the UI
Navigate to the Recycle Bin, find the record by scrolling or filtering, select it, and click Restore. That’s genuinely it in most cases. The record returns to its original location and shows up again in reports, workflows, and standard views.
Where it gets trickier is in environments with a lot of dependencies. Restoring the record is step one. Making sure everything attached to it still works correctly is step two, and that step is easy to skip when you’re in a hurry.
Restoring Multiple Records Via Data Loader, Workbench or API
At volume, the UI isn’t the right tool. Data Loader lets you query deleted records using SOQL with the ALL ROWS clause and then run an undelete operation across all of them at once. Workbench does the same thing through a browser interface if you’d rather not deal with a local install.
Neither approach is plug-and-play at scale. API limits apply, batching takes planning, and the larger the restore job the more time it takes. Budget for that before you promise the business a recovery timeline. And verify the data afterward — relationships don’t always survive a bulk restore intact.
Simplify Large-Scale Data Recovery
Eliminate the complexity of bulk restores and recover data faster with full context intact.
Salesforce QueryAll Delete Records
By default, SOQL queries ignore deleted records entirely. To pull them back into view, use queryAll in the REST API or add ALL ROWS to your SOQL query. This surfaces both active and deleted records, including everything currently sitting in the Recycle Bin.
It’s a useful tool for audits, investigations, and restoration prep. It’s also a tool that can slow things down fast if you run it against a large dataset without thinking through the scope first. Filter aggressively and know what you’re looking for before you run it.
Restoring Parent Records With Child Records In Salesforce
This is where recovery gets genuinely complicated. Salesforce objects are frequently connected through parent-child relationships, like Accounts and Contacts or Opportunities and related records. Restoring them doesn’t automatically rebuild those connections cleanly.
If a parent record is restored before its child records, or if those child records were deleted separately, the relationships may not re-establish correctly. Lookup and master-detail fields may need manual correction after the restore. For organizations that rely on reporting, automation, or integrations built around those relationships, skipping the validation step after recovery tends to create a second problem on top of the first.
How Can Admins and Developers Empty or Purge the Recycle Bin?
There are legitimate reasons to permanently remove data: storage pressure, compliance requirements, cleanup after a migration. Salesforce provides several ways to do it. Treat all of them with care. Once data is permanently deleted, there’s no native recovery path.
How to View All Recycle Bin Salesforce Permission Set
Access to the full Org Recycle Bin is controlled by permissions, specifically “Modify All Data” or equivalent admin-level access assigned through profiles or permission sets. Without it, users only see what they personally deleted.
Worth auditing periodically. The more people who can see the full bin, the harder it is to track who did what when something goes wrong. Keep it limited to the people who genuinely need it.
Using the UI to Empty the Org Recycle Bin and Permanently Delete Records
Inside the Org Recycle Bin, admins can select “Empty Org Recycle Bin” to permanently remove everything currently in there. Immediate. Irreversible. Before running it, make sure nothing critical is still sitting in the bin. In environments where multiple teams are deleting data regularly, that’s not always obvious without checking first.
Executing a Hard Delete via Bulk API or Database.emptyRecycleBin
The Bulk API with hard delete enabled bypasses the Recycle Bin entirely, removing records permanently as part of the operation. Useful during migrations and large cleanup projects where performance matters. Apex’s Database.emptyRecycleBin() does the same thing at the code level for specific records or collections.
Both skip the safety net completely. Use validation steps before running either one, not as an afterthought.
Permissions Required to View and Purge the Org Recycle Bin
Purging the Recycle Bin requires “Modify All Data” level access. That’s a broad permission and should be treated accordingly. Regular audits of who holds it, across both profiles and permission sets, help make sure permanent deletion capability stays where it belongs: with administrators who understand the consequences.
What Are the Options If a Record Has Been Permanently Deleted?
Not many. Once a record is gone through a hard delete, an emptied bin, or automatic purging, native recovery options don’t apply. For most organizations this is the point where a contained data problem starts affecting reporting, automation, and downstream systems in ways that are hard to unwind.
Don’t Let Permanent Deletions Be Final
Ensure your data is always recoverable, even after it’s gone from Salesforce.
Salesforce Data Recovery Service and Its Limitations
Salesforce has a Data Recovery Service. It exists, but calling it a recovery strategy would be generous.
When it works, Salesforce support retrieves data from backend systems and hands it back. The process is slow. It’s not always available. Volume and format are historically limited, and relationships between objects frequently need to be rebuilt manually after the fact. There’s also a cost attached. For organizations counting on this as a fallback, it tends to underdeliver at exactly the moment reliability matters most.
The more useful takeaway is what this service reveals about permanent deletion in Salesforce: once it happens, you’re negotiating with uncertainty. External backup solutions exist specifically to take that uncertainty off the table.
Best Practices for Data Protection & Preventing Accidental Deletes
Protecting Salesforce data means putting guardrails in place before something goes wrong, not building a response plan for after. The Recycle Bin handles short-term mistakes. Everything beyond that requires deliberate decisions about backup, access, and visibility.
Strengthen Your Salesforce Data Protection Strategy
Go beyond native limits with a more reliable and controlled approach to backup and recovery.
Salesforce Data Backup and Recovery Best Practices
A reliable backup strategy is the foundation, and it needs to cover more than just records. Metadata and object relationships have to be included, because restoring records without their context often means restoring something that doesn’t actually work.
The part most teams skip: testing recovery. Having backups is one thing. Knowing you can restore them quickly and completely under pressure is another. Run a recovery drill before you need it. The teams that do this are rarely the ones calling Salesforce support at 2am.
Change Management, Approval Processes & Deletion Permissions
Most accidental deletions aren’t really accidental. They’re the result of too many people having access they don’t need. Limiting delete permissions on critical objects is one of the simplest and most effective things an admin can do. Add approval workflows for high-impact bulk actions and the risk drops further.
Documentation matters here too. When bulk updates or deletions require review before execution, issues get caught earlier and accountability is clear when something still goes wrong.
Monitoring Deletion Activities & Using Change Data Capture
You can’t respond to what you can’t see. Event Monitoring and Change Data Capture give organizations a way to track deletions in real time, who did it, what was deleted, and at what scale. A spike in deletions outside of normal workflows is a recoverable problem if you catch it the same day. A week later it often isn’t.
Costs, Limits & Performance Considerations
Recovery has real implications beyond the technical. Performance overhead, licensing costs, and operational disruption all factor in. These considerations tend to get ignored until an actual recovery is underway and suddenly everything is moving slower than expected.
API Limits When Restoring Large Data Sets
Salesforce API limits don’t pause for emergencies. When you’re running a large-scale restore through Data Loader or Workbench, you’re working within the same limits as everything else hitting your org. That means batching carefully, monitoring usage in real time, and sometimes accepting that recovery will take longer than the business wants it to. Plan for this before you’re in it.
Licensing & Service Implications of Salesforce Backup & Restore
Native backup and restore capabilities exist in Salesforce, but coverage gaps are common, particularly around metadata and complex object relationships. Know exactly what’s included in your current setup before you’re counting on it. Surprises during a recovery effort are expensive in more ways than one.
When Third-Party Solutions Make More Sense Than Native Recovery
At a certain scale, native tooling stops being sufficient. Third-party backup solutions offer longer retention, more granular recovery, and better handling of metadata and relationships. The organizations that tend to find this out the hard way are the ones that assumed native tools were enough until they weren’t. If your data environment is complex or your compliance requirements are strict, it’s worth evaluating purpose-built options before you need them.
Why a Self-Hosted Backup Solution Goes Beyond Salesforce Recycle Bin Limits
The Salesforce Recycle Bin was designed for short-term recovery. It was never meant to be a data protection strategy.
Its 15-day retention window, storage-based purging, and incomplete recovery capabilities make it a poor primary safeguard in environments where data is constantly changing. A self-hosted backup approach operates differently. Data is replicated into an environment your organization controls, with retention policies, access controls, and recovery processes that you define, not Salesforce.
That means data can be retained as long as your compliance requirements dictate, restored on demand, and recovered with full context including relationships and metadata. Recovery stops being a race against a 15-day clock and becomes a controlled, predictable process. GRAX replicates your Salesforce data to your cloud environment, whether that’s AWS, Azure, GCP, or on-prem, with no dependency on Salesforce’s native limits.
Note: The video below was recorded before the CapStorm and GRAX merger. Some product names have since changed, but the core concepts apply.
Video Transcription
My name is Drew Niermann, and this is Data Unleashed, the video blog series dedicated to helping you get more out of your investment in Salesforce.
So we’re gonna start today’s episode with a little quiz about Salesforce’s recycle bin. Do you happen to know how many days deleted data gets retained in Salesforce? If you accidentally delete it? If you’re thinking the answer is 15 days, you would be correct. So congrats to you.
But what if somebody deleted some data, and they didn’t realize it was gone until day 16 or later? Salesforce does not retain the data after that point. And once it’s gone, it’s gone forever, there is no getting it back.
Or maybe someone deletes something, goes to the recycle bin, and they perform a hard delete and clear it out of the recycle bin before the 15-day timer is up. Also in that scenario, that data is gone forever; you’ll never get it back.
Here’s a scenario where unleashing the power of a self-hosted solution is really, really powerful. So think about this. What if you had an infinite-depth, Salesforce recycle bin with object-specific retention policies that you could specify however you want?
That’s exactly what you can do if you take a self-hosted approach to Salesforce backup and recovery. And what I mean by self-hosted is your backups, living behind your firewall in a nonproprietary, standard relational database, where you can get at that data, specify the retention policies, preserve all of the referential integrity of the data model, and then have the database purge the data from your on-prem recycle bin or your self-hosted cloud-based recycle bin on a schedule that makes sense for your data retention and compliance requirements.
So if this is something that you’ve never thought about, or you find interesting, please drop me a note on LinkedIn It’s something that we see every day and we help enterprise Salesforce customers around the world solve this problem every day.
Thank you so much for watching. My name is Drew Niermann and you’re watching data Data Unleashed.
Take Full Control of Your Salesforce Data
Retain, manage, and recover your data without time limits or storage constraints.
FAQs
What Is the Retention Period for Records in the Salesforce Recycle Bin?
By default, Salesforce retains deleted records for 15 days. In Salesforce Classic, admins can enable Extended Recycle Bin Retention to push that window to 30 days. Neither timeline is guaranteed; records can be purged earlier if the Recycle Bin reaches its storage capacity.
How Many Records Can the Recycle Bin Hold and Does It Vary by Edition?
Salesforce doesn’t publish a clean number, but the widely accepted figure is roughly 25x your total data storage allocation. Since storage allocations differ between Enterprise and Unlimited editions, the effective capacity of the Recycle Bin varies accordingly. More storage means more room, but it doesn’t eliminate the limits.
How Do I Restore Deleted Records via the API or Data Loader?
Use queryAll in the REST API or the ALL ROWS clause in SOQL to surface deleted records currently in the Recycle Bin. From there, Data Loader or Workbench can run bulk undelete operations. Validate the results afterward; relationships and dependencies don’t always reattach automatically.
Can I Recover Relationships Between Parent and Child Records?
Not always automatically. Parent and child records may both be individually recoverable, but Salesforce doesn’t guarantee that relationships between them will be correctly re-established during the restore. Lookup and master-detail fields often need manual correction after recovery.
Is There Any Way to Increase the Salesforce Recycle Bin Time Limit?
In Salesforce Classic, Extended Recycle Bin Retention can extend the window to 30 days. The feature isn’t available in Lightning Experience, and it doesn’t prevent early purging if storage capacity is reached first.
How Do Third-Party Backup Solutions Compare to the Salesforce Recycle Bin?
Third-party solutions are built to address what the Recycle Bin doesn’t cover: longer retention, more complete recovery, and preservation of metadata and relationships. For organizations with compliance requirements or complex data environments, they provide a more reliable and scalable foundation for data protection.
