Stop all changes before you touch anything
A mass deletion in a live CRM is one of the few genuine drop-everything moments in Zoho administration. The data itself can usually be recovered. The problem is that every minute of normal activity makes a clean recovery harder.
So before you even open the recycle bin, freeze the system:
- Tell the team to stop. No new records, no edits, no helpful colleague re-typing contacts from memory. Recreated records become duplicates that have to be untangled from the genuine restores later.
- Pause outbound syncs. Zoho Analytics first. If your CRM feeds an Analytics workspace, that workspace still holds the deleted rows as of its last sync. The next scheduled sync removes them. Pausing it preserves a free recovery copy. The same logic applies to Books, Campaigns and any Zapier or Make connection that mirrors CRM data.
- Disable whatever did the deleting, if you know. A Deluge function with a delete call in a loop, a misconfigured integration, a colleague working through a filtered list view. If it ran once it can run again.
- Note the time of the deletion as precisely as you can. The recycle bin and the audit log both filter by time, so the deletion window is how you will find the batch to restore.
If the missing records are the quotes your sales team needs this afternoon or the contact base behind tomorrow’s billing run, that’s what our emergency Zoho developer line is for: a senior developer responds within 30 minutes during UK business hours.
What does the Zoho CRM recycle bin actually hold?
Go to Setup > Data Administration > Recycle Bin. Every deleted record sits there for 60 days, listed with the record name, the module, who deleted it and when. After 60 days Zoho purges it automatically. There is no setting to extend this.
Two things catch people out.
Visibility depends on who is looking. Standard users see only the records they deleted themselves. An administrator sees everything. If the bin looks suspiciously empty, you’re probably signed in as the wrong person. Check with an admin login before concluding the data is past saving.
Deletions from every source land here. Records removed through the API, a Deluge function or a sync tool go to the same bin as records deleted by hand. An integration that wiped 4,000 contacts overnight hasn’t destroyed them. They’re sitting in the bin like everything else.
What comes back when you restore: the record itself with its field values, plus the notes, attachments and activities that were deleted along with it. What does not come back automatically: lookup fields on other records. When a record is deleted, every lookup elsewhere that pointed at it is emptied on the spot. Restoring the record doesn’t refill those fields. Plan a re-linking pass after any significant restore.
How do I restore the records?
In the recycle bin, filter by module, then by the deleting user and the time window you noted earlier. Select the records and click Restore. For a single-record accident that’s the whole job, usually inside ten minutes.
Mass deletions need more care, because deletion cascades further than most people expect. Deleting a parent record drags related data with it and each related item lands in the bin as its own row. Restoring the parent alone does not guarantee the children follow. Work module by module: restore the Accounts batch, then Contacts, then Deals, then anything custom, always filtering on the same deletion timestamp so you pick up the whole batch and nothing else.
Then verify before declaring victory. Open ten or twenty restored records at random. Check the related lists are populated. Check the lookups point where they should. A restore that looks complete at row level but is missing half its associations will surface later as a data-quality mystery.
Who deleted them? Read the audit log
Open Setup > Security Control > Audit Log. Filter by action and you’ll find entries for Delete and Mass Delete showing the user, the module and the time. Export it to CSV if the incident is serious enough to need a paper trail.
You’re answering three questions. Who or what did it: a user, an API client or a function. How: a mass delete from a list view usually means someone selected everything matching a filter that caught more than they realised. And whether it has stopped: an integration that deletes on sync will cheerfully delete your restored records on its next run, so make sure it stays paused until the restore is done.
One pattern deserves a special mention. If the deletions trace back to the account of someone who recently left, you may be looking at clumsy offboarding. Deleting a leaver’s records instead of transferring them is a classic mistake. Our guide on what to do when your Zoho super admin leaves covers how to wind down a departed user’s account without losing what they owned.
What if the 60 days have passed?
Now you’re shopping for copies. In rough order of usefulness:
Zoho’s own backup module. Setup > Data Administration > Backup. If anyone ever scheduled CRM backups, this is where the archives come from: a zip of CSVs per module. Check it first, even if you think nobody set it up. Sometimes a careful predecessor did.
Old exports. Ask the team whether anyone exported the module recently. A mail merge, a board report, a list sent to the accountant. A three-month-old CSV sitting in someone’s downloads folder has rescued more CRM data than any clever tool we know of.
Synced applications. Zoho Analytics holds CRM rows as of its last sync, which is exactly why pausing it was step one. Books holds customer and vendor records. Campaigns holds contact details. None of these gives you the full record with its history, but names, emails and key fields are usually enough to rebuild a working dataset.
A sandbox. If your CRM has a sandbox refreshed before the deletion, it contains production data as of the refresh date.
Recovery from any of these means importing CSVs back into CRM. Set duplicate handling to skip on email or a unique ID so you don’t trample the records that survived. Be aware of what import cannot give you: restored records get new record IDs, so anything keyed to the old IDs, such as integrations or Analytics joins, needs reviewing afterwards. Attachments from a backup cannot be pushed back through the import wizard either; re-attaching is manual work or a small API job. And if the import rejects rows, our guide to why Zoho CRM skips records on import explains the skipped-records file that tells you exactly why.
What is genuinely gone?
A short list, because false hope wastes recovery time:
- Records purged past 60 days with no backup, export or copy in a synced app. Gone.
- Records deleted from the recycle bin itself. Emptying the bin, or deleting individual entries from it, is permanent immediately.
- Previous field values. The bin holds deleted records, not old versions of surviving ones. If someone mass-updated a field and overwrote 5,000 job titles, the bin is no help at all. Backups or synced copies are your only sources.
Then there is Zoho support. Their stated position is that data purged from the recycle bin cannot be restored; they do not run per-customer point-in-time restores from their infrastructure backups. Raise a ticket anyway in three situations: the bin shows nothing for a deletion you know happened minutes ago, you cannot attribute the deletion to any user or integration (reset passwords too, because that pattern can mean a compromised account) or you suspect a Zoho-side sync fault did the deleting. In those cases support can investigate things you cannot see. Just build your plan as if the data-restore answer is no, because it almost always is.
Quick diagnostic checklist
- All record changes stopped and the team told why
- Zoho Analytics and other outbound syncs paused
- The cause disabled: function, integration or misunderstood filter
- Recycle bin checked while signed in as an administrator
- Deletion batch identified by user and timestamp in the audit log
- Records restored module by module from the same batch
- Related lists and lookup fields spot-checked on restored records
- Past 60 days: backup archives, old exports and synced copies located
- Scheduled backups switched on for next time
When to hand this to someone who does it weekly
Most single-record accidents end happily in the recycle bin. Mass deletions, cascades across modules and anything past the 60-day line are a different class of problem, where a rushed restore can do more damage than the deletion did. A fair share of the systems we look after arrived mid-crisis. Our Zoho support service covers the recovery itself and the backup schedule that should have existed beforehand. Prices are published on our pricing page and discovery consultations are free. Get in touch and for standard work a developer is assigned within 24 hours; genuine emergencies go through the 30-minute line mentioned above.