I'm designing an enterprise desktop application where the user will be able to send folders and documents to the trash.

Are there any standards that suggest an optimal time to automatically purge the trash if at all?

1 Answer 1


In consumer products, like OneDrive or Dropbox, a 30 days long persiod seems to be an unwritten standard. Enterprise-grade products, however, handle it differently. To continue my example:

  • At Dropbox, being able to recover files for more than 30 days is a premium feature calledm Extended Version History. Purchasing it means that you can go back to previous versions of any file within a year of deletion or edit.
  • At Microsoft, the exact number of days depends on the actual product your company subscribes to (on SharePoint Online it's 93 days, for example – I'd be curious how they came up with that number). However, it's common for their offerings to have a second stage recycle bin, which keeps files you (or the passage of time) deleted from the "ordinary" recycle bin. While I haven't seen any research or reasoning behind it, I think it's super useful – I, for one, often delete a bunch of files as part of a clean-up and then empty the recycle bin immediately, only to realize there were some files sitting there I should have restored first.

In the end, from a UX perspective, generally the longer the better – the only drawback in choosing a longer period lies with the complexity it brings if you don't frequently empty the recycle bin on your own, and want to find one exact file you accidentally deleted. This is why having two recycle bins seem to be such a good idea: you can empty the first trash sooner (like, after 30 days) to keep it organized and easy to find stuff in, while the second one can help in case someone really needs to recover a file deleted long ago.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.