Trash, History & Rollback

Every change to a file is timestamped, and you can always roll back to an earlier point in time. This page covers the lightweight, per-entry mechanism for that: trash and per-file history. For the multi-file, atomic changeset-and-checkout system, see Version Control - that's a different, heavier tool for coordinating a whole set of changes together, not a replacement for this one.

Trash#

Deleting a file doesn't remove it immediately. It soft-deletes into a per-user trash, visible in the web dashboard's Trash view.

You can delete from either place - your file manager (Finder, Explorer, or the command line, on the mounted drive) or the web dashboard. Both do the same thing: the file goes to trash, not away. Deleting a folder takes its contents with it, so your file manager will refuse to remove a folder that still has files in it - empty it first, or delete it from the dashboard if you mean to take the whole thing.

Each org sets a retention window - anywhere from 1 to 3650 days - that controls how long a deleted file stays recoverable before it's permanently purged. Until that window elapses, restoring a file from trash brings it back in place, at its original path.

History and rollback#

Because every change is timestamped, a file's full edit history is available at any time, and you can roll back to any point in that history - not just the most recent save. This is scoped to a single entry: rolling back a file doesn't touch anything else in the project.

Trash and history vs. version control#

Trash and history operate one entry at a time, with no concept of grouping changes across files. If you need to restore a whole folder or project to how it looked before a coordinated set of changes - a batch of asset updates that need to move together, for example - that's what the changeset/checkout system in Version Control is for.