What happens to a deleted document in Clio

Deleting a document in Clio does not erase it immediately: it moves to Clio Manage's trash, where it stays restorable for up to 30 days, after which it is permanently removed. That's the whole recovery mechanism, and everything else on this page follows from it. If the document you're looking for was deleted inside the last month, go to the trash in Clio Manage and restore it. Today, not next week.

The complication is that "the document is gone" gets used for at least four unrelated events. Somebody deleted the record. Somebody dragged a file out of the mounted Clio Drive folder, which syncs both ways and is therefore the same deletion wearing different clothes. Somebody uploaded a revision onto the record and the version you wanted is now the previous one. Or somebody re-uploaded a file under the same name and there are now two records where you expected one. Only the first two are deletions at all, and only they use the 30-day window; the other two are version-history questions with completely different answers. Work out which one happened before you spend a day on the wrong fix.

Two caveats before you go looking. A safety net you've never touched is one you're guessing about: find the trash once on a throwaway document in a test matter, while nothing is at stake — not on the afternoon a filing goes missing. And restoring may not be yours to do: which user roles can see and restore from the trash follows from Clio's permission tiers, so the person who notices a deletion isn't necessarily the person who can undo it. Confirm the current per-role behavior in Clio's help center for the roles your firm actually uses.

When a new version is uploaded onto an existing document record, Clio retains the prior versions rather than overwriting them, and you can view or download any earlier one. That covers the most common "we saved over it" panic: the letter you sent last week is still readable even though the record now shows this week's revision. Clio's web interface has no one-click revert, though. To make an older version current again, you add it back as a new version using the plus icon next to the document's version history — so describe the fix accurately when you hand it to someone else: you're pulling an old version forward, not rolling the record back.

The limit worth knowing is that version history only covers revisions deliberately uploaded as versions of that record. A file uploaded alongside the original is a separate document with its own history, and the two never converge. So the discipline that makes recovery possible later is a filing habit now: when a document is genuinely being revised, upload the new version onto the existing record rather than creating a second one. A matter with one record and six versions is recoverable in a way that a folder of six near-identical files isn't.

Two boundaries on this. Clio's version history begins at upload — it can't reconstruct the revision trail a previous document system kept, which is covered in the document metadata guide. And a re-upload of a file whose name already exists in the folder may land as a version of that document or as a second record beside it. If you already have two same-name records, read both before deleting either; the compare is cheap and the delete starts a 30-day clock. The outcome that bites is the one you didn't expect, so confirm which way this behaves in Clio's help center.

Two questions come up here, and only one has a clean answer. Start with the clean one. The portal shares the specific documents and folders you publish to it, so a client sees a document because someone deliberately shared it — and a folder you've shared keeps sharing whatever you add to it afterwards. The full mechanics of that are in the permissions guide.

The question without a clean answer is whether a client can remove a document through the portal, and what happens to a file a client uploaded there. Both guesses are expensive. "The client can delete it" and "the client can't" lead to different workflows, and assuming the wrong one costs you either way. Portal capabilities vary by plan and change over time, so confirm the current behavior in Clio's help center before you build a workflow that depends on the answer.

What you can decide without waiting for that answer is the posture: the matter's Documents area is the copy of record, and the portal is a distribution surface. If a client sends something through the portal, treat the matter as the place it has to end up, and confirm it's there. Then hold on to the asymmetry no software fixes. Unsharing isn't unsending. A document a client has already downloaded is out of your control regardless of what you do afterwards in Clio, which argues for care at the moment of sharing rather than confidence in a retraction.

Clio governs what a person can do through their user role and permission tier, combined with which matters they have access to — not through per-file locks. So "who can delete this document" resolves to "who is on this matter, and what does their role permit," and tightening it means scoping matter access rather than locking a file. The permissions guide walks the layers. How granular the delete-specific capability gets is plan-gated and has moved over time, so check it against the roles your firm actually uses rather than inferring it from how another system worked.

Because the recovery window runs out in a month, the leverage is almost entirely upstream. Four habits do most of the work. Keep the set of people who can remove documents small and deliberate. Brief every Clio Drive user that dragging a file out of the mounted folder is a firm-wide delete rather than a local tidy-up. That's the deletion people commit without realizing they deleted anything, and the Clio Drive guide explains why the sync behaves that way. Upload revisions onto the existing record so version history is populated when you need it. And keep a naming convention consistent enough that same-name collisions stay rare.

The fifth habit is the one that survives everything else failing: know where your out-of-Clio copy comes from. A matter's folder downloaded as a .zip at close-out, or Data Escrow's weekly backup, is what remains once the 30 days are up. That's the only thing that still helps six months after a deletion nobody noticed. Where that copy itself lives is a storage-venue decision with custody consequences rather than a folder on somebody's desktop — the firm's duties toward the file don't lapse because the copy is a backup. It's a decision, not a project.