How Deletion Works
What happens when you delete a contact, company, deal, activity, or follow-up — and how to recover if you delete the wrong thing.
Deletion Is Permanent
Every CRM deletion in Sarudo is a hard delete — contacts, companies, deals, activities, and follow-ups are removed from the database when you ask for them to be deleted, and there is no trash / archive / undo view you can recover from through the app. This is a deliberate choice: soft-delete with a trash folder adds complexity that no current client has asked for, and for the cases where recovery matters (bulk import went sideways, wrong record deleted) the right recovery path is the backup system, not an in-app undo. If you want soft-delete added — a `deleted_at` column and an UPDATE-instead-of-DELETE pattern — it is a feature request, not shipped today.
Your AI employee always confirms before deleting anything. "Delete the ACME contact" triggers a "are you sure? This will permanently remove the contact record and any orphan activities/follow-ups — confirm with /approve" response before the delete fires. That confirmation gate is the only safety net on top of the backup system.
What Cascades, What Gets Orphaned
When you delete a parent record, the related records are handled differently depending on the entity. Deleting a contact removes just the contact — any activities, follow-ups, or deal-participation records that referenced that contact may be orphaned (their `contact_id` points at a row that no longer exists). Deleting a company first unlinks every contact in that company (their `company_id` is set to NULL so the contacts themselves are preserved), then deletes the company record. Deleting a deal removes the deal — activities and follow-ups referencing that deal via `deal_id` are handled by the foreign-key policy in the schema (cascade-deleted or orphaned depending on the current FK config). Deleting an activity or a follow-up removes just that row; nothing else is touched.
The "orphaned vs cascaded" distinction matters mainly for reporting — orphaned activities will still appear in activity-list queries but will not have a valid parent link. If you want a clean delete, delete the children explicitly first, or ask your AI employee to "delete the ACME contact and all related records" so the full chain is handled at once.
Recovery If You Deleted the Wrong Thing
If you accidentally delete something important, recovery is possible via the backup system — but only up to the freshness of the most recent backup. Daily backups run at 03:00, so the worst-case loss window is roughly 24 hours. For anything you are about to do that touches many records (bulk imports, cleanup scripts, mass status changes), trigger an on-demand backup first — "take a backup before this cleanup" — so the restore point is fresh. See the Backups & Data Export article in Getting Started for how restores are coordinated.
Recovering from an accidental bulk delete
Pull back records that were deleted within the last day.
Before a Bulk Delete
If you are about to delete many records in one pass — cleaning up a test dataset, archiving a defunct product line, removing a departing client and all their history — the safe rhythm is always: (1) trigger a fresh backup, (2) run the delete, (3) verify the result. The backup is cheap (a single pg_dump) and ensures that if the delete touched something it should not have, you have a clean recovery point from seconds before the operation rather than hours before. Your AI employee will prompt you with this sequence when you ask for a bulk delete, so you rarely have to remember it yourself.
If you want compliance-grade deletion (for example, a customer exercising a GDPR / CCPA right-to-be-forgotten request), the hard-delete default is exactly what you need — the record is gone, not hidden. If you want compliance-grade auditability (a paper trail showing when and why a record was deleted), pair the delete with a knowledge-base entry capturing the rationale.