Permissions vs. Restrictions | Confluence Access Series

[Robert Hean]

Some of the most frustrating parts about Confluence are how we can control access. For example, you may see a page, but your manager may not. Someone in another department can edit something that you can’t, or maybe some random person on the internet can see YOUR planning docs for some reason.

To help untangle Confluence access I’m kicking off a multiple part series on Permissions and Restrictions. This is an important topic for everyone to understand as it directly impacts what you can do (or not!) in Confluence. This series will cover global permissions, space permissions, the 

First up we’ll tackle some basic concepts around access, including what the difference is between permissions and restrictions….

Permissions vs. Restrictions

The term “permission” and “restriction” seem to be interchangeable in Confluence - but they’re not! At a high level permissions define what you can do in an instance or space, while restrictions define what you can do to specific pieces of content.  And, to make it more interesting, there are also two levels of permissions - global and space (we’ll dig into each of these in future posts). 

Permissions

I tend to think of permissions as what I can do in a space or instance. For example, there is a permission that lets you archive content, and another one that lets you comment. Permissions give space admins (fairly) granular control over who can do what in their space. This makes it easy to tailor access to a specific purpose - for example allowing analysts the ability to view and edit content, but not create new stuff.

Permissions also make it easy to completely hide a space from someone - just remove their “view” permission and they can’t see anything in the space.

Restrictions

 

I think of restrictions as the “fine tuning” within a space (we’ll dig into these as we go as well!). Restrictions are also the source of a LOT of frustration as it’s easy to accidentally restrict content and not realize it. View restrictions also have a concept called “inheritance” that allows child pages to get the same restrictions as parents. This can be insanely frustrating as team members will complain of things disappearing, or that they can’t see something their teammate can.

Homework

Surprise! there's (entirely optional) homework...

Understanding the difference between permissions (space and instance level, what you can do) and restrictions (content-level) is the first step in untangling how they work. To help you understand the different here’s some homework (but no math!):

1. Take some time to jump into Confluence and see if you can determine what permissions you have (or if you’ve got Space Admin access go look at the permissions setup in a space).
2. Find a piece of content and see if you can figure out how to restrict it to just yourself. Then ask a teammate to go open it and see what happens.

 Drop a comment when you complete this and let others know what you found.

What’s next

Next we’ll dig into global permissions. These control what an individual can do across Confluence. 

Drop your questions/comments about permissions/restrictions below, and hope to see you soon!

[Stephen_Lugton]

Thanks for the article @Robert Hean 

We are very much into Role Based Access (RBAC), and being able to use groups for user permissions simplifies this.

For instance, in my role as an Agile Delivery Manager in the Technology team I'm told that I have no need to see the Product team's space.

However, in my role as a Confluence admin I have full access to unrestricted pages such as the Product team's space.

Unfortunately we have found issues with restrictions, such as when a page was restricted to certain people all of whom left over a couple of years, and we then needed the information on that page to request a £600k+ tax rebate.  It took half a dozen people from 4 departments 6 months to work out what information might have been on that page and submit our tax rebate request, but we don't know if we missed anything.