The Perfect Permission Scheme

Constantly bombarded with users asking questions about why they can’t do XYZ or why they can’t see a certain issue? Look no further. Introducing the (nearly) Perfect Permission Scheme for Jira and Jira Service Desk.

With our experience auditing different Jira instances, we found that permissions can look incredibly different across instances. We’ve seen closed permission schemes where most users can’t transition an issue and alternatively, we’ve also seen open schemes where nearly everyone is an administrator. Neither of these schemes are perfect.

In this blog, we dissect the various permissions that Jira has to offer and provide recommendations on how you might configure those permissions.

Configuring Permission Schemes

Jira allows the user to apply a permission to about ten different sets of people. In the following section, we’ll go over three potential sets so that when you start applying permissions to your instance, you’ll understand what each set contains. Refer to this handy image from Atlassian’s documentation about how groups and roles apply to permissions. Use it as a reference should you get lost in this blog.

Application Access

The first and most broad way to apply a permission is through application access. You can grant a permission to any user that has access to any of the Atlassian products that you deploy. For example, you could grant anyone with Jira access to the “browse projects” permission. This allows anyone who can log into Jira the ability to see all the projects in your instance.


Groups are a tad bit more complicated. In a Jira Cloud instance, you can create as many groups as you’d like (assuming you’re a Site Administrator). If you are using Jira Server you can create groups as well, but your organization might have an Active Directory that they are using to manage their users and groups. Learn more about connecting to a user directory here.

All in all, you can have groups for different departments or teams. With these groups, you can grant permissions within a permission scheme.


Roles are managed at the project level. Within a Jira project, a Project Administrator can assign different users or groups to project roles. Jira Administrators can also create new project roles through the administration panel.

Since the developers, users, and administrators roles are all included out-of-the-box we will use these in addition to the ones that are created if you have Service Desk installed. The Service Desk roles are Service Desk Team, Service Desk Customers, and Service Desk Collaborators. We will only apply permissions at the role level.

Note: We don’t mention the “Atlassian Add-ons” role because it should be granted for all permissions except delete issues.

Understanding Project Permissions

Administer Projects

By definition, this is the ability to administer projects in Jira. This means all options in the project settings will be available.

We suggest granting it to the project role, “administrators”. By default, anyone who creates a project will be added to that role. If they want to pass that responsibility onto someone else, they can simply add them to that role within their project.

Verdict: Administrators

Browse Projects

Users with this permission can view projects and the issues within them.

Assuming you have added the right users to the right roles in your project, this is fairly straightforward. This is ideal if you would like most of your team to see the issues in the project.

Verdict: Administrators, Developers (sprint managers), Service Desk Customers, Project Team (Service Desk Team Role), Project Participants, Users

Manage Sprints

This is the ability to manage all aspects of sprints. From creating a sprint to starting it to closing it – This permission covers it all.

Who are the people that are creating your sprints? Do you have scrummasters? Perhaps your product managers are managing the scrum team. Depending on who would normally manage your scrum team’s sprint, they should be given this permission.

Verdict: Developers (sprint managers)

Service Desk Agent

This is possibly the most sensitive permission as these users interact with your customers via Service Desk. We would suggest using the project role that comes with Jira Service Desk for this and adding your agents to that role.

Verdict: Administrators and Service Desk Team

View Development tools

In the permission scheme, you will see that this permission “allows users in a software project to view development-related information on the issue, such as commits, reviews, and build information.” That being said, it is advisable to leave this open for your entire development team.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team Role)

View Read-only Workflow

At Atlas Authority, we are a transparent organization. It’s important that our team knows about the underlying workflow, which is controlling the process of their work. Therefore, being able to view the read-only workflow is important.

Verdict: Administrators, Service Desk Customers, Project Team

Issue Permissions

Assignable User, Assign Issues, Close Issues, Edit Issues, Link Issues, Move Issues, Schedule Issues, Resolve Issues, Transition Issues, Modify Reporter, Set Issue Security
Being able to collaborate with your teammates is very important. That’s why for these eleven issue level permissions, we recommend granting them to three roles. Users need to be able to know what they are working on and then pass that work along to the next person for review or further development, thus the assign and transition permissions.

Once that work is done, they should be able to close the issue out and/or resolve it. Therefore, closing issues and resolving issues is important.

Users should also be able to create issues in the correct project and if an issue needs to be moved to another project, it should be possible to do so as well. They should be able to edit those issues, link them to other issues, and schedule when they should be done. These are all characteristics of a highly collaborative team. Therefore, create, edit, link, move, and schedule should all be granted.

Verdict for all: Administrators, Service Desk Customers, Project Team (Service Desk Team)

Create Issues

For creating issues it is the same as above, but you would also like your issue participants to create issues.

Verdict: same as above plus Project Participants (Service Desk Collaborators)

Delete Issues

The last issue permission can be sensitive to your Jira instance whether you are using cloud or server. If an issue goes missing, it is likely that it was deleted. Once an issue is deleted from a cloud instance, it is gone forever, there is no retrieving it. That is why it is important to only allow nobody to delete your issues.

Verdict: Nobody

Note: Jira Administrators can always add themselves to this permission if it’s necessary to delete an issue

Voters and Watchers Permissions

Manage Watchers

Knowing who is interested in an issue (watcher), is integral in prioritizing issues in your backlog. Most users involved in working on issues should have this permission.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team)

View Voters and Watchers

Simply being able to see who is interested in an issue, on the other hand, is great for the team to understand the prioritization of the issue. Therefore, this is a permission we can open up.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team), Users

Comments permissions

Add Comments and Edit Own Comments

Collaborating with your teammates is vital to all organizations. Communication fuels how your coworkers learn and grow.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team), Project Participants (Service Desk Collaborators)

Delete Own Comments

This is essentially the same as the add and edit comments. For transparency sake, we don’t want collaborators to delete their comments on issues.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team).

Delete All Comments, Edit All Comments

That being said, editing or deleting each other comments are not necessary. With a single rogue user, this could create chaos.

Verdict: Administrators

Attachment Permissions

Create Attachments, Delete Own Attachments

Giving users the power to control their own attachments helps them manage their work better. Having the ability to create attachments is essential. There may be some useful information they need to add to an issue. Alternatively, with the possibility of human input error, one may mistakenly upload the incorrect attachment so having the option to delete attachments is incredibly useful.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team), Project Participants (Service Desk Collaborators)

Delete All Attachments

Removing unwanted attachments should be granted to the administrators only since it could cause confusion if users can delete each other’s attachments.

Verdict: Administrators

Time Tracking Permissions

Delete All Worklogs, Edit All Worklogs, Log Work for Others

This is another example of granting only administrators the ability to control others’ work. Deleting coworker’s worklogs should not be granted easily. Neither should editing others’ worklogs or logging their work for them.

Verdict: Administrators

Delete Own Worklogs, Edit Own Worklogs, Work on Issues

Again, this is about being able to control your own work. Users should be empowered to log time, edit their logged time, and delete if necessary.

Verdict: Administrators, Service Desk Customers, Project Team (Service Desk Team)

Ability to Create Permissions

So there you have it – A nearly perfect permission scheme for every organization. This permission scheme is fairly open and allows users to manage their work, but not others. The management of other people’s work should lie in the hands of your trusted group of Administrators.

If you’re short on resources or time and find that you need guidance creating the perfect permission scheme for your organization or need help with Jira implementation services, please contact us! We’ll be happy to help get you up and running.