When you delete an article or a collection, they don't disappear immediately. First they go to the Trash, where they're kept for a limited time (depends on your plan). During this period you can restore something accidentally deleted with one click, or, conversely, wipe everything permanently.
Deleted spaces do not go to the trash — they are kept for 30 days in the "Deleted spaces" section of the Settings → Spaces page (see the Spaces article for details).
Trash protects you from "fatal" mistakes like "picked the wrong folder and hit Delete," and at the same time gives the admin a single point for final organization cleanup.
#Where to open it
Left menu → Trash (the trash icon at the bottom of the navigation).
The badge to the right of the item shows how many objects are currently in the trash.
Who can see the section:
- Organization Owner — deleted articles and collections from all spaces; organization Admin — from corporate spaces and private ones where they are a member (deleted spaces are in Settings → Spaces)
- Space Editor or Admin (with any organization role except Guest) — deleted articles and collections from the spaces where they have that role
- Guest and anyone without the Editor or Admin role in any space — the section is hidden
#What goes into the trash
Deleting either of the two object types is a soft-delete: the record stays in the database with a deleted_at mark, but is hidden from users and AI search. Restoring brings the object back "as it was."
| Type | Where it's deleted from | What goes into the trash |
|---|---|---|
| Article | article context menu → Delete | the article itself (its content is preserved) |
| Collection | collection context menu → Delete | the collection + all articles inside it |
Deletion is cascading: if you delete a parent collection, all nested collections and articles move to the trash along with it.
#Retention period by plan
How long an object stays in the trash before permanent deletion is determined by your plan:
Once the period expires, a background process permanently wipes the object from the database — along with its associated chunks, embeddings, and AI answer cache. It can no longer be restored.
Tip. If for compliance reasons you need to hard-delete an object right away, use "Delete permanently" manually instead of waiting for the cron.
#What a trash item looks like
Each trash row is a card with the object type, name, short description, who deleted it and when, the remaining time, and action buttons:
Color indicators of remaining time:
- Green — more than half the period is still ahead
- Yellow — less than 30% of the period left (time to decide: restore or delete permanently)
- Red — 1–2 days left until permanent delete
#Actions on a single object
#Restore
| Type | Where it returns |
|---|---|
| Article | to its original collection. If that collection is also deleted, choose another one in the restore dialog |
| Collection | with all its content as of the moment of deletion |
After restoring, the object's deleted_at and deletion_scheduled_at marks are cleared — it's available again in the normal interface and appears in search.
#Delete permanently
Irreversible deletion right now, bypassing retention. A confirmation appears with an explicit warning that "this action is irreversible." Use it only if you're sure — it can't be undone.
#Preview (articles only)
Opens a thumbnail with the title and the first 800 characters of the content. It's a quick way to remember what's inside without restoring the article.
#Filters and search
At the top of the page is a filter bar:
- Type — articles, collections, or all together
- Search — by name (case-insensitive)
- Mine only — objects deleted by you personally
- Period — a range of deletion dates (from/to)
- Pagination — up to 50 items per page
#Bulk operations
Tick the checkboxes on several cards — a bulk action bar appears at the bottom:
Separately, in the top-right corner of the page, there's an "Empty trash" button — it permanently wipes deleted articles and collections in the spaces where you are a space admin (you can restrict it to a selected type, e.g., "articles only"). This action requires confirmation. The content of deleted spaces is not shown in the trash, and "Empty trash" does not affect it.
#What happens to search and AI while an object is in the trash
While an article is between deleted_at and deletion_scheduled_at:
- In normal search results and AI answers for users, the deleted content is not shown
- Embeddings and cached AI answers remain untouched in the database
- The AI may cite a deleted article in answers from the cache — if the same question was asked before deletion and the answer was cached
This is a deliberate trade-off: we allow "undoing" a deletion without a full reindex of the organization (which is slow and expensive), while the cleanliness of public search is ensured by the deleted_at IS NULL filter at the SQL query level.
If you need to immediately purge an article from the cache, use "Delete permanently": the cron will immediately remove both the embeddings and the associated cache records.
#Privacy and access
- The Owner sees the entire trash; an Admin sees everything except private spaces they are not a member of
- A space Editor sees only objects from the spaces where they have the Editor or Admin role; Guest and anyone without such a role in any space don't see the trash. Others' spaces aren't shown at all
- Private space — a colleague who is not a member sees neither the space nor its deleted items
This is the same privacy model as in the main interface — the trash doesn't break it.
#Who can delete and restore what
Trash actions are decided by the role in the object's space (Space Admin / Editor / Viewer). The organization role matters because the Owner is an admin in every space, and a Guest is never above Viewer. The table columns are the role in the object's space (the last one — organization Admin or Owner):
| Action | Viewer | Editor | Space Admin | Admin / Owner |
|---|---|---|---|---|
| Open the "Trash" section | — | ✓ | ✓ | ✓ |
| See an article preview in the trash | — | ✓ | ✓ | ✓ |
| Delete an article (send to trash) | — | ✓ | ✓ | ✓ |
| Restore an article | — | ✓ | ✓ | ✓ |
| Delete an article permanently | — | ✗ | ✓ | ✓ |
| Delete a collection (to trash) | — | ✓ | ✓ | ✓ |
| Restore a collection | — | ✓ | ✓ | ✓ |
| Delete a collection permanently | — | ✗ | ✓ | ✓ |
| Delete a space (to "Deleted spaces") | — | ✗ | ✗ | ✓ |
| Restore a space | — | ✗ | ✗ | ✓ |
| Delete a space permanently | — | ✗ | ✗ | ✓ |
| Empty the entire trash | — | ✗ | ✓ | ✓ |
Key rules:
- An Editor can send to trash and restore, but "deleting permanently" articles and collections is limited to Space Admin (and above). This is a safeguard against accidental data loss by a regular employee.
- Spaces are the most powerful operation: an organization Owner can delete, restore, and permanently delete any space; an organization Admin — corporate spaces and private spaces where they are a member with the admin role. A Space Admin of a single space cannot delete the space itself. Deleted spaces are restored and permanently deleted in Settings → Spaces, not in the trash.
- A space Viewer and a Guest don't see that space's trash — and can't delete or restore anything. An organization User with the Editor or Admin role in a space does see that space's trash.
- A private space is deleted by the organization Owner or by an organization Admin who is a member of it with the admin role.
Important about cross-space restore. If you restore an article into a different space (e.g., the original was deleted), you must have a role of at least Editor in the target space — otherwise the restore will be rejected with an
INSUFFICIENT_PERMISSIONSerror.
#Related sections
- Audit log — the
trashed/restored/permanently_deletedevents are logged there with the initiator and time - Article management — this is where the normal deletion that sends an article to the trash happens
- Spaces — a deleted space and its content are kept for 30 days in Settings → Spaces, not in the trash