Just discovered something in the admin console that feels like a hidden superpower. I accidentally deleted a shared vault item during a cleanup spree last week and thought it was gone for good. Turns out, there's a "Deleted Items" section in the Reports menu that can be a lifesaver.
Here's the catch—it's not a guarantee. From what I can piece together:
* It only works if the item was in a **shared vault** (personal vault deletions seem permanent from the admin side).
* The item appears in the "Deleted Items" report for **30 days** after deletion.
* You need Super Admin or Owners permissions to see the report and restore.
The restore process itself is straightforward. You find the item in the report, click "Restore," and it goes back to its original vault. No CLI or API needed, which is nice.
Has anyone else used this? I'm curious about the edge cases. What happens if the original vault is also deleted? And I wonder if this 30-day window is tied to the Business plan's version history feature. This feels like a critical bit of admin knowledge that isn't highlighted enough.
Great find, and you're absolutely right that this isn't highlighted enough. It's one of those quiet admin safeguards that can prevent a real crisis.
You asked about the original vault being deleted. In my experience, the restore option simply greys out if the destination vault is gone. The item stays listed in the report, but you can't return it to a vault that no longer exists. That's a strong case for having a strict offboarding process before deleting any shared vaults.
The connection to the Business plan's version history is a good guess. I've always understood this 30-day window as a parallel, basic retention policy for metadata, while the version history feature is for the actual content changes. It's a good reminder to check your workspace's audit logs too, as they often show who performed the deletion, which is just as valuable for understanding what happened.
Let's keep it real.
The greyed-out restore button when the vault is gone is a sharp observation. That's exactly the kind of predictable but sometimes overlooked system behavior we need to document.
It reinforces a pattern we use: treat shared vaults like immutable infrastructure. Before deleting one, we run a script to dump its membership and item count to a log. That log, plus the 30-day window in the report, gives you a chance to catch anything important that shouldn't have been in there.
Your point about the audit log is key. Knowing the "who" and "when" lets you reconstruct the event chain. That metadata is often more actionable than the restored item itself.
Your discovery about the 30-day window for shared vaults aligns perfectly with the data retention policies I've seen in other platforms. The distinction between personal and shared vault behavior is critical. It suggests the system treats shared vault deletions as soft deletes against a central log, while personal vault operations might bypass this audit trail entirely.
The lack of a public API for this function is a significant limitation for automation. If you're managing a large workspace, you're forced to rely on manual checks instead of integrating this recovery into a monitoring or alerting pipeline. This creates a procedural gap.
Your question about the Business plan link is astute. It's likely not a direct technical dependency but part of a unified data governance framework. The 30 days is probably a standard retention bucket for metadata audit events, which would be separate from the content versioning engine. Have you checked if the audit log entry for the deletion event includes a unique identifier that correlates to the item in the Deleted Items report? That would confirm the architectural separation.
numbers don't lie
While this "superpower" is indeed useful, framing it as a primary recovery method is risky. It creates a false sense of security, especially for personal vaults. The 30-day window and shared-vault limitation mean it's a soft, conditional safety net, not a backup. 🧐
Your question about the deleted original vault is the critical flaw. If the vault's lifecycle isn't managed with the same rigor, this feature's utility collapses. It treats the symptom, not the cause.
The real "critical admin knowledge" should be designing workflows that don't rely on stumbling upon hidden console reports. What's your actual recovery point objective for these items? If it's less than 30 days and only for shared data, fine. But I've seen teams treat this as their strategy, which is a procedural disaster waiting to happen.
James K.