Salesforce holds the records your sales, service, and marketing teams work from every day. When some of them disappear, the question is never academic. Someone needs them back, and they need to know how long they have.

Salesforce offers several ways to restore deleted Salesforce records, but they do not behave the same way. Some return the original record with its ID and relationships intact. Others only let you rebuild a copy, which quietly breaks every lookup, integration, and report that pointed at the old record.

This guide is organized around where your records actually are right now.

Quick answer: To restore deleted Salesforce records, open the Recycle Bin, set the view to All Recycle Bin, select the records, and click Restore. This works for 15 days after deletion. Once that window closes, the records are permanently deleted and can only be rebuilt from a backup or an export.

Quick Recovery Decision

Find the row that matches your situation, then go to the matching section. Every decision here comes down to two questions: is the record still soft deleted, and does the original record ID survive.

Undelete vs Restore vs Re-create

These three words get used interchangeably. Salesforce does not treat them the same way, and the difference decides whether your data comes back whole.

• Undelete recovers a soft-deleted record still sitting in the Recycle Bin. The original record ID returns with it, along with its relationships and audit fields. Nothing downstream breaks.
• Restore writes records back into your org from a backup snapshot held by a backup product. Whether the original ID is reinstated depends on the tool and how the restore is configured.
• Re-create inserts brand new records from data you exported earlier, whether a Data Export CSV, a sandbox copy, or a report. Salesforce assigns new IDs, so every lookup, master-detail link, and integration mapping that pointed at the old ID has to be rebuilt by hand.

Undelete is always the outcome you want. Re-create is the fallback when nothing else exists.

First, Confirm That the Record Was Deleted

A surprising share of "deleted" records were never deleted. They were reassigned, reparented, or hidden by a sharing change. Rule that out first, because an unnecessary recovery creates duplicates you then have to clean up.

1. Search for the Record Across Salesforce

Start with Global Search rather than a list view. If nothing returns, ask an administrator or a user with View All Data on the object to search for you. If they can see the record and you cannot, the problem is access, not deletion.

2. Check Related Lists and Record Relationships

If you were looking in a related list, check whether the record was reparented. A record that moves to a different parent vanishes from the list you expected without ever being deleted. Global Search will still find it. Open the record and check its parent lookup field.

3. Check Permissions, Ownership, and Sharing Rules

Ownership changes and sharing rule changes both remove records from a user's view without touching the data. Ask your administrator whether ownership was transferred, whether the record moved to a different role or territory, or whether organization-wide defaults changed recently.

Choose the Correct Salesforce Recovery Method

Each method recovers something different and carries a different time limit. Compare them before you start, because some of these paths are one-way.

Restore Deleted Salesforce Records from the Recycle Bin

This is the fastest path and the only one that returns the original record untouched.

1. Open the Recycle Bin from the App Launcher.
2. Set the view to All Recycle Bin to see records deleted by every user. My Recycle Bin shows only your own deletions.
3. Search by name, or sort by deleted date to find recent deletions.
4. Select the records and click Restore. They return to their original object with their original IDs.

Two limits govern this window, and both matter more than most admins expect.

The time limit. Salesforce holds deleted records for 15 days by default, and this is not configurable in Lightning Experience. In Salesforce Classic, an administrator can enable Extended Recycle Bin Retention under Setup > User Interface to extend the window to 30 days, and it applies only to records deleted after it is switched on.

The capacity limit. The Recycle Bin holds roughly 25 times your org's data storage allocation in megabytes. When it fills, Salesforce purges the oldest records to make room, even if they are two days old, with no alert. In orgs running high-volume integrations or regular mass deletions, the real window can be far shorter than 15 days. See our breakdown of Recycle Bin retention rules for how this plays out.

If the bin was emptied manually, or the records were hard deleted through the API, they are not there and never will be. Skip to the backup section.

Bulk Undelete Records with Workbench

Restoring hundreds of records one page at a time is not realistic. Workbench can undelete in bulk from a CSV of record IDs, and it still respects the 15-day window.

First find the records. In Workbench, go to queries > SOQL Query, tick Include Deleted and archived records, and run a query against the affected object:

SELECT Id, Name, LastModifiedDate, LastModifiedById
FROM Account
WHERE IsDeleted = true
ORDER BY LastModifiedDate DESC

Download the results, keep only the Id column, and save it as a CSV. Then go to data > Undelete, choose From File, upload the CSV, map the Id field, and confirm. Workbench returns a results file showing which IDs succeeded. Salesforce Data Loader performs the same operation, and Workbench is not an officially supported Salesforce product, so use whichever your team has standardized on.

Check Deleted Records Using Data Loader

If you cannot find the records in the Recycle Bin interface, query for them directly. This tells you whether they are still soft deleted or already purged.

In Salesforce Data Loader, use the Export All operation, not Export. Export All calls the queryAll API, which returns soft-deleted records and archived activities. A standard Export returns nothing no matter what filter you apply. You need API Enabled and View All Data on the object, so you may need an administrator to run it.

You can also check from Apex using the ALL ROWS keyword, which must run in the Developer Console anonymous window rather than the Query Editor:

// Run in Developer Console > Debug > Open Execute Anonymous Window.
// ALL ROWS is not valid in the Query Editor or in the REST and SOAP APIs.
List<Account> deletedAccounts = [
    SELECT Id, Name, LastModifiedDate
    FROM Account
    WHERE IsDeleted = true
    ALL ROWS
];
System.debug(deletedAccounts.size() + ' deleted Account records found');

One important limit: these queries only surface records still in the Recycle Bin. Once Salesforce purges a record it is not queryable through any API. If the query returns nothing, you are working from a backup or an export from here.

Restore Parent and Child Records in the Correct Order

Deleting a parent cascades. Child records in a master-detail relationship, and in some lookup configurations, go to the Recycle Bin with it. That works in your favor: restore the parent and the cascaded children come back automatically, still linked.

Order matters. Restore the parent first and verify the related lists repopulated before touching anything else. If the children were deleted separately rather than cascaded, they will not return with the parent.

Restore Records from an Available Backup

Once the Recycle Bin window closes, the question is what independent copy you hold. Ask your administrator which of these exist, in this order of usefulness:

• A backup product with a restore function, whether Salesforce Backup or a third-party solution. This is the only category that puts records back rather than handing you a file.
• A recent Data Export ZIP, if it is still inside its 48-hour download window or was saved somewhere durable.
• A recent Full sandbox copy, containing production data as of its last refresh.

Recover Data from a Recent Full Sandbox

Full sandboxes copy production data as it existed at the moment of the copy, so they can hold records since deleted from production.

Two caveats. Full sandboxes can only be refreshed once every 29 days, so the copy may be up to a month stale, and a sandbox template can exclude objects from the copy entirely. If the records are there, export them with Data Loader and import them into production. This is a re-creation, not a restore, so the records arrive with new IDs.

Considerations for Restoring Records from the Recycle Bin

User Permissions

Any user can restore records they deleted themselves from My Recycle Bin. Restoring records deleted by other users requires the Modify All Data permission, which is what grants access to All Recycle Bin.

Deleted Records Visibility

Regular users see only their own deleted records. Administrators and users with elevated permissions see deleted records from all users in the organization.

Retention Period

Records are retained 15 days by default and can be purged sooner if the bin hits its capacity limit. After that they cannot be recovered through the Recycle Bin, and there is no Salesforce service that will retrieve them for you.

Deleted Records Restoration

Users reach the Recycle Bin through the App Launcher. Depending on permissions they can switch between My Recycle Bin and All Recycle Bin, select records, and click Restore.

Data Integrity and Relationships

Salesforce restores associations that have not changed since deletion. If they changed afterward, for example because the parent was reparented or deleted separately, they may not restore correctly. Check related lists after every restore.

How to Recreate Permanently Deleted Records

Once records are purged you are rebuilding, not recovering. Salesforce documents several methods of importing data, but the import is the easy part. Data integrity takes the time.

Understand Record IDs and Relationships

Recreated records are assigned new unique record IDs. If you are restoring an Account and its related Contact records, recreate the Account first, then update your Contact file to replace the old Account ID with the new one before importing the Contacts.

Map Old IDs to New IDs Before Importing Child Records

Build the mapping before importing anything downstream. Import parents first, then export the Data Loader success file, which contains both the old ID and the newly assigned one. Use VLOOKUP or XLOOKUP to rewrite the parent ID column in every child file.

A cleaner approach is a custom External ID field, marked unique, holding the original record ID. Child records can then be related through the External ID instead of the Salesforce ID, which removes the manual mapping step and makes the import repeatable. Work down the hierarchy in order and verify each level before starting the next.

Retain Historical Metadata

Recreated records normally show today's date and your name in their audit fields, which destroys the historical record and creates real problems in a regulated environment. Salesforce's Create Audit Fields feature preserves the original values, with prerequisites worth knowing first.

• What it covers. Four fields: CreatedById, CreatedDate, LastModifiedById, and LastModifiedDate.
• How to enable it. From Setup, enter User Interface in Quick Find, select User Interface, then select the checkbox enabling the "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" user permissions. This is org-wide.
• Permissions. Grant Set Audit Fields upon Record Creation to the users who need it. Custom profiles can receive it directly; standard profiles cannot be modified, so use a permission set.
• The limitation that catches people out. Audit fields can only be set at the moment of creation, through an API tool such as Data Loader. You cannot edit them afterward. Decide before you load, or your only option is to delete and reimport.

If the original owner is now inactive, you also need the Update Records with Inactive Owners permission for ownership to carry over.

Recovering from Weekly Backups

Salesforce's Data Export Service produces CSV files containing your org's records, which gives you something to rebuild from. It is worth being precise about what it is not.

Data Export does not run on its own. An administrator has to run or schedule it. Enterprise, Performance, and Unlimited editions can export once every 7 days; other supported editions once every 29 days. Files are available for 48 hours and then deleted, and starting a new export immediately deletes the previous one. Data Export has no restore function and does not include metadata.

Access the Weekly Backup Files

Confirm with your administrator whether an export ran recently and whether the files were saved outside the 48-hour window, then download the ZIPs covering the timeframe you need.

Locate the Deleted Records

Open the CSVs for the objects you need and find the deleted records using identifying details. Verify each record's relationships and confirm the file is formatted correctly for import.

Import Records into Salesforce

Use Data Loader to load the data. Import parents first to generate their new IDs, update the child files with those IDs, then import the children and confirm relationships resolved.

Recreate Deleted Records with Data Loader

Salesforce Data Loader is a client application you install locally for bulk import and export. It can insert, update, upsert, delete, and export records, through its interface or from the command line. It cannot bring back a purged record; it creates new records from data you already hold.

1. Select the Correct Operation and Object

Log in with your Salesforce credentials, which means either OAuth or username plus password plus security token depending on your org. Choose your environment deliberately, since this is where most accidental production loads begin.

Choose Insert to create new records from your backup file, or Upsert if you are matching on an External ID and want to avoid duplicates on a second run. Then select the object. If the one you need is missing, check your permissions on it.

2. Map Required Fields and External IDs

Browse to your CSV and map its columns to Salesforce fields. Data Loader auto-matches exact name matches; map the rest by hand. Map every required field or the batch fails validation. For child records, map the parent relationship field to the new parent ID column, or to your External ID field. Save the mapping file so you can reuse it.

3. Import, Review Error Logs, and Validate the Results

Run the operation. Data Loader writes a success file listing created records with their new IDs, and an error file listing failed rows and why.

Read the error file first. Common failures are validation rules, unmapped required fields, retired picklist values, and duplicate rules firing. Fix the source and reload only the failed rows. Keep the success file, because it is your old-ID-to-new-ID map for the next level of the hierarchy.

Salesforce Native Backup and Restore Options

Salesforce ships several native tools that touch data protection. It helps to be clear on which ones can actually restore.

• Recycle Bin. Restores soft-deleted records with original IDs, for 15 days, subject to the capacity limit.
• Data Export Service. Produces CSV files on a 7-day or 29-day cycle by edition. No restore function, no metadata.
• Data Loader and the APIs. Move data in and out on demand. They do not back anything up; they are how you use a copy you already hold.
• Salesforce Backup. A paid add-on, generally available since 2023, that automates backups and restores records into the org. It is licensed separately from your edition and priced per user, and it focuses on data rather than metadata. Confirm current terms with Salesforce or your account executive.

Only the last of these restores anything after the 15-day window, and it has to be licensed and configured before the incident.

When Is a Full-Organization Restore Appropriate?

This used to describe a paid Salesforce service that recovered an org from Salesforce's own backups. That service no longer exists. Salesforce retired its Data Recovery service on July 31, 2020, citing a minimum turnaround of 6 to 8 weeks and no guarantee of complete recovery. There is no last-resort number to call, at any price.

Full-org recovery is now something you provision for in advance through a backup product, or something you do not have. It is appropriate when damage is broad rather than targeted: a bad data load that overwrote thousands of records across objects, a failed deployment that corrupted data alongside metadata, or a ransomware or insider incident affecting a whole environment.

For anything narrower it is the wrong instrument. Rolling an org back to a snapshot discards every legitimate change made since, which usually creates a second and larger cleanup. Granular restore, down to the object, record, or single field, is what most incidents call for.

Restore Deleted Objects With Third-party Backup

A third-party backup product covers the gap the native tools leave open: recovering records after the Recycle Bin has expired, with relationships intact and without a manual rebuild. Flosum is an end-to-end enterprise DevSecOps platform purpose-built for Salesforce, and its Backup & Archive product handles this case. The workflow below applies to most enterprise backup tools.

1. Select the Salesforce Org and Recovery Point

An administrator opens the backup or archive section, selects the Salesforce org, and chooses the recovery point: the snapshot taken before the deletion. If you are not certain when the deletion happened, work backward from the earliest confirmed sighting of the missing data rather than guessing.

2. Select Records and Related Objects

Select the specific records to restore. This is where granular tooling earns its keep, because most incidents affect a defined set of records rather than a whole object. Flosum supports granular, field-level recovery, so you can restore a single field on a single record without rolling back everything around it.

Include related objects deliberately. Restoring accounts without their contacts leaves you a second problem; restoring children without parents produces orphans.

3. Configure Restore Options and Validate in a Sandbox

Restore options typically include creating new records, overwriting existing ones, or skipping records that already exist. When recovering from a deletion, create new records is normally correct. Overwrite replaces current production values with backup values and will discard legitimate changes made since the snapshot.

Run the restore in a sandbox first whenever the volume or the relationships are non-trivial. Validate record counts and relationships there, then run it in production and check the results log rather than assuming it finished cleanly.

Post-Recovery Validation Checklist

A restore that reports success is not the same as a recovery that worked. Walk this list before you call the incident closed, and confirm the data recovery process actually put things back the way they were.

• Record counts. Compare records restored against records expected. Investigate any gap.
• Parent-child links. Open a sample of restored parents and confirm related lists repopulated. Look for orphans with empty lookup fields.
• Ownership. Confirm correct owners, particularly where original owners are now inactive.
• Audit values. Check CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById. If they all show today and your name, the audit history is gone.
• Flows and triggers. Restoring records fires automation. Check for side effects such as duplicate tasks, unwanted emails, or incorrect field updates.
• Reports and dashboards. Refresh affected reports and reconcile against what they showed before the deletion.
• Sharing and access. Confirm the right users can see the records. Sharing recalculates on insert, and manual shares do not survive a re-creation.
• Integrations. If external systems store Salesforce record IDs and you recreated rather than undeleted, those references now point at nothing. Update every affected mapping.

Restore Deleted Records Quickly and Prepare for the Next Incident

The decision path is short. Deleted within 15 days and still in the Recycle Bin? Undelete, and you get the originals back, IDs and all. Deleted in volume? Use Workbench or Data Loader to undelete in bulk inside that same window. Window closed? You need a backup product that can restore. No backup product? You are rebuilding from an export, with new IDs and manual relationship mapping, and there is no Salesforce service to fall back on.

Which means the real decision is not made during an incident. It is made beforehand, when you decide whether an independent, scheduled backup with granular restore is worth having.

Flosum Backup & Archive uses Composite Backup, which retrieves new, changed, and deleted data from Salesforce and joins it with the unchanged data already in your backup container, and supports restore down to the individual field on an individual record.

Want to see what recovery looks like when the Recycle Bin is not your only option? Schedule a call with our team.

Frequently Asked Questions