Retention & erasure

There are two ways to remove a document, and the difference matters.

Ordinary delete — reversible

Delete is a soft delete. To delete a file:

1. Right-click the file in the Files list (or click the ⋮ button at the end of its row) and choose Delete… — the last item, in red. You can also open the file’s details drawer and click Delete… at the bottom; both do exactly the same thing.
2. Type the reason. Every partner who could see the file is told it word for word, so it can’t be left blank.
3. Choose whether to email them: OK tells them; Cancel deletes quietly (your choice is recorded).

Anyone who can edit the project’s Files can delete. The one thing that can’t be deleted is a published CDE record — archive it instead. An issued, shared or transmitted file can be deleted; that is exactly when the partners who held it are told why. A file already waiting in the queue isn’t offered again.

The document leaves the folder and moves to Pending deletions on the Retention page (the Files group in the sidebar). From there you can:

• Restore it back to where it was, or
• leave it — its bytes and history are retained, just out of the way.

Nothing is destroyed. This is the everyday “get this out of the active tree” action, and it’s always undoable. A deleted document keeps its record and can still be found in the queue.

Legal erasure — permanent

Erase permanently is different in kind. It exists for a legal erasure request — PDPA / GDPR / APPI “right to be forgotten” — where you must be able to attest that the material is gone, not merely hidden. It:

1. Destroys every version’s bytes in storage.
2. Removes all derived knowledge — anything the platform extracted from the document (the same purge as removing an inbox item).
3. Deletes the document’s rows, including any share links (the links go dead).
4. Leaves one trace: an entry in the erasure ledger recording what was erased, when, by whom, and the reason you gave.

Our nightly backup of stored files still holds a copy of the bytes for a while: the next night’s backup moves it aside, and, once deletion from the backup is switched on (we are switching our deletions on one at a time), it is deleted from there 89 days later, so within 90 days of the erasure. That holds while the nightly backup runs: if it fails or stops, the copy stays until it runs again. If a request needs the backup copies gone sooner, contact ddx support.

Because it’s irreversible, the action asks for two things: a reason (the legal basis — required, and it’s the one thing the ledger keeps) and the document’s name retyped to confirm. It’s available to workspace admins on the filing surface.

You can only erase a document you can open. One classed above your clearance answers exactly as if it did not exist — it is not named, and nothing happens to it — so ask someone who can open it.

Caution

Erasure cannot be undone and is not for tidying up — use Delete for that. Reach for erasure only when you’re satisfying a formal erasure obligation.

Notices about a document

A share or issue is held for the partner’s “files shared” summary before it is sent (see delivery partners). Those held rows carry the recipient’s address and go with the document when it is erased, with the project when it is deleted, and — while still waiting — with a person removed from the delivery space. Rows already sent stay for a year, like the delivery log, because they are what stops a file being announced twice (see how long things are kept).

The erasure ledger

The Erasure ledger (on the same Retention page) is the permanent, append-only record of every erasure on the project: the document name, the reason, who did it and when. It’s what you show to demonstrate that an obligation was met — the ledger persists precisely because the document doesn’t.

The ledger remembers who was allowed to see each erased document. You see an entry’s document name and reason only if you could have opened the document before it was erased. Otherwise the entry shows as Restricted document, with its dates, its counts and who erased it, but no name and no reason. The reason is withheld because it often names the person the document was about.

Entries made before the ledger started keeping this show in full to workspace admins only.

What about partner uploads?

A delivery partner’s uploads belong to the project record. Revoking a partner’s access ends their portal, but doesn’t erase what they filed — that stays part of the project’s history and is subject to the same two mechanisms above.