Now that we have some basic concepts down (check out this post for them!) let’s dig into permissions.
Permissions control what we can do in Confluence. For example, there is a permission that lets you archive content, and another one that makes you a Space admin. To add some more complexity there are two types of permissions - Global and Space.
An important thing to remember about permissions is that they are additive. For example, if I’m in one group that doesn’t include “Create Space”, but I’m given it by membership in another group, I will have that permission. This means things can quickly get confusing as more and more groups are created and used (and reinforces the need to know your Organization admin!).
Another important thing to remember is that Confluence admins has complete control of the instance. This means they can override space admins on various settings (like public links), and even view content that is otherwise restricted (via the admin key).
We’ll save space-level permissions for our next issue, but here we’ll dig into global permissions.
Global permissions define what individuals can do across the entire Confluence instance. These are managed by the Confluence Admin and are typically things that are set up when Confluence is installed and then left alone. I loosely group them into two groups - individual permissions and access permissions.
This group provides specific permissions to individuals who have a Confluence license. First there is “Create Space”, which allows someone to create new Spaces in Confluence. Typically I see this only provided to a limited number of folks. This helps ensure that spaces are created appropriately (e.g. you don’t end up with three versions of “Support Team”). Most places I work with reserve this permission to either admins or a (very) small set of individuals. It’s also worthwhile to put a process in place for requesting a new space from these folks (e.g. through Jira Service management) to help manage everything.
Next up is “Personal Space” which provides a space to each licensed individual named after them. This is one of my favorite parts of Confluence as it gives users a place they can go to make their own content, experiment with things and basically do whatever they want. It’s an important safety valve (since it lets them make anything) and a useful tool to let folks use Confluence.
The next group contains permissions that allow different types of access to your Instance, including Guest, Public Links and Anonymous access. Note that both Public Links and Anonymous Access can be controlled at the space level by space admins, but MUST first be activated by Confluence admins.
Guest access has to be defined by your Org Admin, but if it is, Confluence Admins can manage it at the instance level. Guest access can be incredibly useful if you need to pull in a non-licensed individual, however, keep in mind it is very limited access and only intended for very focused, targeted use.
Public links can also be enabled, or disabled, instance-wide by Confluence admins. Public links allow users to share content with anyone on the internet, which can be useful but can also be risky (since anyone can see that content!). Confluence Admins can see how public links are being used across the instance, including how many are active and how many views they get. Crucially, Confluence admins can also turn off public links in a specific space, and prevent space admins from turning them back on.
Anonymous access takes public links a step further and lets anyone on the internet access Confluence. This also means it will show up in search engine search results… which can be good (in the case of public facing documentation) and absolutely terrible (in the case of sensitive information). Typically groups I’ve worked with keep this off!
There are two additional options for global permissions that are less frequently thought of. These are “App” and “JSM” access.
App access controls what marketplace apps can do in Confluence, although it’s important to note that this doesn’t represent the totality of their access as they can also be added at the space level. Globally, however, Apps have similar access to a person:
Note that changing these can impact how the app works!
JSM access lets you give access to Confluence to agents, even if they don’t have a Confluence license. This helps ensure your agents can get access to articles to resolve tickets without needing to get them a license. There’s two options here, Use Confluence and View User Profiles.
Technically not a permission, but Confluence admins have access to other tools that let them manage Confluence including the admin key and space admin permissions.
The admin key lets a Confluence admin access any content in Confluence. This is something that should be used sparingly, however, it can help untangle access if someone leaves the company, or if emergency access is needed. Keep in mind that using this is logged by Confluence and will alert the content owner (so it’s not something you can be sneaky about…).
Next Confluence admins can grant themselves Space admin access at any time for any space. This is similar to, but different from, the admin key as it provides space-level permissions. This is useful for helping troubleshoot permissions or recovering access in the event a Space admin isn’t available. Like the admin key, this is also logged.
Wrap Up
Global permissions control what individuals can do across an entire instance and are only accessible by Confluence admins. They also happen to be a setting that groups setup once and tend to forget about, so it’s worthwhile to review them once or twice a year.
Curious your thoughts on global permissions - what frustrations do you have with them? What questions? Drop them below!
Rob Hean
0 comments