Archiving vs Deleting
Even the best content may need to be removed from your content hierarchy. This might be for a number of reasons, but mainly boils down to something no longer being relevant or accurate. Regardless of why, it’s just sitting there, taking up space. At best this will be a visual annoyance to folks browsing the space (or searching!). At worst, however, this un-needed content can result in people making decisions based on bad or outdated information.
Fortunately, Confluence gives us two powerful (but very different!) tools to manage all of this - archival and deletion.
Archival
The archive is a special part of every space that contains archived content. It is accessible to anyone with space access. Individuals with the “archive” permission can place content into the archive, edit the note on it, and even un-archive it. This places a lot of power in the hands of folks with this permission, as they can choose to add or remove archived items at any time. This isn’t necessarily bad, however, it is something you may want to keep an eye on.
When content is archived it will be removed from the content hierarchy. This means it will disappear from the sidebar and that specific macros (like Page Tree) won’t show it. It will also be suppressed in search - however - you can choose to “include archived content” when searching to find this content. Hyperlinks to the content will still work, however, archived content has a bar at the top clearly indicating it is archived (and a note if one was added).
Archived content can also optionally include a short note (For those of you of a certain age this is limited to the original length of a tweet on Twitter!) explaining why it was archived. Always include a note. This is the only chance you have to give context to others (including yourself!) on why the content is in there. Individuals with the archive permission can also go in and update the note at any time.
If something needs to be unarchived it can be restored to any spot in the hierarchy. Confluence will even remember the content’s original parent and suggest that as a starting point. Child content may optionally follow archived parents, and will retain that parent/child relationship in the archive. This means you can archive a branch of your hierarchy, and then restore that branch to the same location if needed. If you do not archive children with the parents and then restore the parent the old parent/child relationship will not be restored.
While in the archive, however, content will retain restrictions. This means if you have a highly restricted piece of content and it is archived the restriction is retained. In order to view it, however, individuals will need to BOTH be its View restriction AND have the “Archive” permission.
Deletion
I think of deleting something like throwing it in the trash under my desk. I don’t have to look at it all the time, but it’s still in my office. Once that trash can is picked up by the garbage truck, however, it’s gone. Deletion on Confluence follows a similar, two step process. Someone (the access) can delete content and it will disappear from the content hierarchy, however, it is not really gone. It is moved into the space’s trash, where it waits one of three fates at the hands of a space admin:
- Nothing - Items can exist in the trash forever
- Restore - Items can be pulled out of the trash. They’ll appear at the bottom of the space’s hierarchy with no restrictions.
- Purge - Permanent deletion. It’s gone. Forever. No one can restore it (even Atlassian!).
Purging can be done on an item-by-item basis, or the entire trash can be purged at once. Purging is not reversible, so once this happens that content is forever deleted. (Not even Atlassian can restore it!).
Restored content will be returned to the space’s hierarchy, however, unlike archived content there is no option to return it to a specific spot - it will always be dropped at the bottom of the hierarchy. Restrictions are also not retained, so anything restored in this manner is visible to everyone with view access to the space. Due to this I usually wait for after-hours or times when most people won’t be online to restore.
When deleting parent content you can optionally send its children to the trash as well. If you opt NOT to do this, children will be bumped up one level in the hierarchy. This can have unintended impacts on restrictions as that content has a new parent. Also note that once content is in the trash it no longer has any structure - so if you delete something with children, that parent/child relationship is lost. You can restore all the content, but you’ll have to manually fix the relationship.
Permissions
Both of these features are controlled by space-level permissions. This means your ability to do either can vary from space to space (which can be confusing and frustrating! When in doubt, chase down a space admin and ask for help). Typically groups will restrict the ability to delete things, since at best this requires an admin to intervene and pull it out of the trash, but at worst can result in content being permanently removed from the system.
In the new RBAC permissions set there are three permissions that relate to archiving and deleting content:
- Archive Content - allows someone to archive any content they can view.
- Delete own content - allows someone the ability to delete only content they created.
- Delete any content - allows someone the ability to delete any content they can view
Typically groups will allow “Archive Content” for a wide range of folks, with “Delete own” a bit more narrow, and “Delete any” very tightly controlled. There are also some interesting combinations where your Space admins (the people who can purge the trash) don’t get “Delete any” access - this helps segregate duties and prevent potential abuse.
Cheat Sheet!
This table breaks down the differences between delete and archive:
|
Topic |
Deletion |
Archival |
|
Restoring |
Bottom of hierarchy |
User-indicated spot |
|
Permission |
|
|
|
Still accessible |
No, only listed in trash |
Yes, in archive or vial URL |
|
Permanent? |
Yes, if purged |
No |
|
What happens to restrictions? |
Entirely removed |
Retained in archive |
|
What happens to child content? |
|
|
|
Note providing context? |
Nope |
Optional (ALWAYS ADD ONE) |
Wrap up
These are important actions in a space as they help us keep it fresh and relevant. I highly recommend taking time to think through your policy / approach to both of these, and then sharing that with your team. Curious how you handle them… share in the comments and drop your questions!
Was this helpful?
Thanks!
Rob Hean
2 comments