Delete documents — and what happens next
How deletion works, the three conditions that block it, and the honest answer on recovery: there's no recycle bin to restore from, but the server keeps the files where an administrator can reach them.
At the end of this guide you'll know how to delete one document or a batch, why a delete is sometimes refused, and — the part worth reading before you need it — exactly what recovery looks like, because there is no recycle bin to click.
Deleting
Delete appears in the document's actions menu, in the Folder Browser's right-click menu, and on the multi-select bar for a batch (the Delete key works on selected documents too). The confirmation is blunt on purpose:
"This document will be permanently deleted from the system." — "This action cannot be undone."
Read it as written. Confirming with the red Delete removes the document from every folder, search, and queue.
When deletion is refused
Three conditions block a delete, each with its own message:
| Message | Why |
|---|---|
| "You do not have permission to delete this document" | Deletion is permission-gated per document type — most users don't have it, by design |
| "Cannot delete a checked-out document" | Someone's editing session holds it; check in or undo the check-out first |
| "Cannot delete a document that is on an approval process" | Routing has to finish or be ended before the document can go |
A fourth, rarer one asks for patience rather than action: if indexing or workflow is still processing the document, wait for processing to finish and try again.
In a batch delete, blocked documents don't stop the rest — you'll get "Some documents were not deleted" with the reason per document.
What "permanently" actually means
From your side of the interface: gone. There is no recycle bin, no restore button, no undo — nothing a user (or even an administrator, in the web interface) can click to bring the document back.
One honest step behind that: when a document is deleted, the server moves its files — every version, plus its metadata — into a Deleted Content area on the server's own disk, outside Content Central. That's a safety net for genuine accidents, not a feature: reaching it means the server administrator locating the files by hand and re-capturing what's needed. If something important was just deleted, tell your administrator now, with the document's name and folder — the files are recoverable in the way a shredded-then-taped letter is, not the way a trash-can icon is.
Deleting on purpose, at scale
If documents are being deleted one by one to enforce "we don't keep these past X years," stop — that's what retention policies are for: scheduled, reviewed, recorded disposition per document type, instead of someone's Tuesday afternoon and a permission most people shouldn't hold.
Success check: delete a test document, then search for it — no results — and confirm your administrator knows where Deleted Content lives on the server before the day someone needs it.