How to minimize the workload of providing access to Jira projects and Confluence spaces.

[#1]

This article has been created in close collaboration with @Ignacio Pulgar whom I am very thankful for all the guidance. Thank you!

Hi Atlassian Community!

When it comes to user management in bigger instances, it is often handed over to Project Administrators for various valid reasons. To be able to hand over this responsibility, Jira admins decide not to use groups for projects and spaces access and instead adding users individually.

In this article we are going to share how to help Project Administrators minimize the effort of individual project and space access.

Why is it better to add users individually instead of using groups?

Before going into the solution for the work minimization of the individual access of projects and spaces, we should answer why this approach is considered better.

Users can be provided with Project Administrator permission therefore they can grant access to Jira projects and don’t rely on Site Admins. The same can be done for Confluence spaces by granting users with Admin permission.

Transparency

Since users are not able to view who belongs to which group, Project Administrators can’t identify who already has access to the project or if users who shouldn't be able to access it are indeed granted the access.

In this situation Site Admins often get requests to give access to users who can already view the project/space.

Thanks to the transparent approach, by giving individual access, Project Administrators can easily control user’s access and protect the sensitive data.

Dependency

In the situation when Site Admins are not available or their queues are extremely long, space and project access would be blocked.

By transferring the responsibility to Project Administrators we are removing the bottlenecks and are able to provide faster support for new project joiners.

Thanks to moving this responsibility from Site Admins, they are able to provide faster support for the tasks that they are the only people who can support it and focus on on the tasks that can bring the most value to the project/spaces and instance.

The article created by @Ignacio Pulgar  covers this topic in more detail - What is the best way to provide access to projects and spaces?

Minimizing access workload

There are several methods for reducing the administrative workload of managing project and space access.

Minimizing Jira project access workload

Merging existing Jira projects

If the projects managed by the same person are accessible to the same or similar group of users, it is a good idea to merge them it one project. To recognize different workload within the merged project we suggest using native Components field.

A bulk move operation will help moving the issues to a single project, as well as setting the appropriate Component.

Even if just one team should have access to all issues in a given project, while another set of users should only have access to their own issues, it is still possible to set a solution for having that requirement met using a single Jira project.

Also note that filters, boards or dashboards can be created to display different sets of issues from the very same project, therefore having separated views with no need for using multiple projects.

Creation of new projects

To minimize the effort even more, ask yourself if the new project can be avoided and managed in already existing one. That way Project Administrator have to manage access only for one project instead of multiple ones.

Minimizing Confluence space access workload

It is also a good idea to reduce the number of spaces managed by one person if multiple spaces need to be accessed by the very same set of users, or by a very similar one.

If it is possible, simply merge existing spaces and create new sections instead of creating new spaces, in one Confluence space.

To restrict access to some of the pages to selected users, you can use Page Restrictions.

Future possibilities

Atlassian Teams

Atlassian has developed a relatively new feature for users to be able to manage Atlassian teams.

The possibility of using these Teams in the project and space access management will be revolutionary, making it much painless and user friendly for Project Administrators.

Jira - Confluence integration

Some time ago, there was a suggestion of a new feature for Atlassian to help better integrate permission between Jira projects and theirs linked Confluence spaces - Delegation of space access permissions to its linked Jira projects.

This feature would reduce the administrative workload of dealing with project and space access, although it is uncertain if Atlassian will add this feature to their backlog.

What are your thoughts on this topic?

Are you for or against merging some of the projects and spaces into one?

Or maybe you have another idea how to minimize the effort of managing projects/spaces access?

We would love to hear your feedback on this subject!

[John Dunkelberg]

It sounds like the root cause of the problem you describe is that groups in such a configuration are not understandable and transparent.  At our company, groups come from our AD and are clear in description and visible in population in the other shared applications (Outlook, Sharepoint, etc.)  Our primary groups are by reporting structure, which then matches the general use case for Jira and Confluence.  If you see "Group John Dunkelberg" has a Developer role in the project, anyone in our company can easily know that means people reporting to me.  Then we don't need to do the wasteful effort of adding and removing individuals when they join the company, leave the company, or transfer between teams.

I do agree that linking Jira and Confluence permissions would be great and would reduce waste.  In general it's disappointing that Atlassian hasn't tied these flagship products together better.