Space Permissions | Confluence Access Series

[#1]

After Global permissions, our next stop in understanding Confluence access is to explore space-level permissions. These are what most people think of when they think of Confluence access since they are what determine what most people can do in the system. For example, your ability to view and create content, add comments, and archive things are all controlled by space-level permissions. Here we’ll get a look at what they used to look like, and the new role-based-access-controls (RBAC) that are rolling out. Our next edition will dig into new permissions we get with the RBAC rollout.

Space admins are responsible for managing space-level permissions, although it is important to remember that Confluence admins have the ability to become a Space admin if they need to!

But first....

Space permissions also underwent an overhaul in late 2025. They moved from the “legacy” controls and changed to “role-based access controls”  (RBAC). This means that instead of having to manage individual permissions for every user or group, Confluence admins can now define roles (e.g. “admin”, “collaborator”, “viewer”) that combine multiple permissions. Space admins can then assign these roles to individuals or groups, granting individuals access. This removes a lot of the guesswork that can go into permissions, and also helps reduce administrative overhead.

RBAC is still technically in Beta, so there are some groups that are in an intermediate step between the two permission “versions”. Space admins in instances that still use this intermediate step will continue to have the ability to fine-tune access by editing roles. Eventually, however, everyone will be on the new RBAC setup - this means space admins will only be able to assign roles, while Confluence admins are responsible for configuring them.

What’s in a role, anyways?

Quite a lot, actually! Roles serve an important purpose in systems - they make administration and compliance a lot easier. On the administration side, roles remove the need for admins to configure each user or group separately. In the legacy setup, admins would have to remember which specific boxes to check for each user and group in every space. This makes it incredibly easy for an admin to make a mistake and give someone the wrong access (or miss something entirely!). It also takes time. You have to go in for each individual or group and tick a bunch of boxes.

On the compliance front, the legacy method was… well… a nightmare. Any Space admin could make any change to space-level access at any time. This makes it nearly impossible to ensure folks have appropriate access, and makes auditing a virtually insurmountable challenge. (I’m thankful I never had to run a compliance audit!)

The introduction of roles solves these problems since roles will be managed by Confluence admins. This means only a small group of individuals will even have the ability to change roles. Changes to roles will also be audit-logged, meaning there is a trail of what changes were made when and by whom. Roles also simplify things for space admins, since instead of having to remember which specific combination of legacy permissions someone needs, they just pick a role from a drop-down. Got a new team member who needs to edit, but not create, content? Give them editor. Got someone who only needs to view and comment? Try collaborator.

There are a number of “default” roles that are provided, but as of writing, Confluence admins can add up to 10 more custom roles.

Space-level permissions

It’s important to remember that permissions control what you can do at the space level - NOT at the content level. For example, giving someone “View” access to a space will let them see the entire space, whereas the “view” restriction is only applied to a single piece of content.

Which brings us to the “view” permission. This is what controls access to the space. Without it, you can’t see anything, so regardless of any other permissions that exist, you MUST have this one (RBAC will remove all permissions if you remove this one!). Personally, I like this setup, since it makes it very easy to instantly remove an individual or group. It also aligns with the general concept of “make everything as accessible as possible”. Confluence is intended to be an open place for collaboration, so being able to easily open up a space fits in with this.

It is also important to note (and, I find it, a bit odd) that blogs are treated slightly differently than the other types of content (pages, databases, smart links, whiteboards, folders) and have their own set of permissions. My guess is that this is a legacy configuration from when blogs were first introduced. Confluence originally only had pages and blogs as content types, which suggests blogs were built separately. As new content types were added (whiteboards, etc) they were added to the same back-end structures that pages use. This resulted in blogs being left on their own. I find this a big odd since it means you get slightly more granular control over blogs, but have one more thing you have to manage.

Some of the other important permissions include:

• Edit - this controls the ability to edit content (note that “blogs” have a separate one of these!).
• Delete - the ability to delete content. Note that deleting content isn’t initially permanent as space admins can recover items from the trash. Typically, however, this permission should be used very sparingly. Instead grant “archive”.
• Archive - the ability to place items into the archive. Use this instead of delete!

Maintenance

Depending on how busy a space is, space-level permissions could be configured once and forgotten about, or used daily. Regardless of use, however, space admins should make time to regularly review and adjust permissions. Team members will come and go, roles will change, new demands will come up, and it’s very easy to forget to adjust your permission to match that.

The easiest way to do this is to put a calendar reminder for yourself. Include a link to space settings and a note that says something like “Review space permissions in XYZ space”. If your environment requires some more controls or audits, you could also easily setup an automation that creates a checklist on a regular basis for you to run though. 

Wrap Up

Space-level permissions are what folks tend to think of when they think of permissions, so they’re very important to understand (even if you’re not an admin!). Curious what thoughts you have - drop a comment below with your ideas and questions!

#confluenceArticle #confluence