Permissions for company-managed projects

Project permissions are managed in two ways:

1. Jira administrators manage project permissions for company-managed projects through permission schemes. This page discusses the individual permission grants available to company-managed permission schemes.

2. Project administrators manage project permissions for team-managed projects through custom roles. Read more about custom roles in team-managed projects.

Here’s a list of the permissions you can grant to define permissions in your company-managed software, service project, or business projects through permissions schemes. Learn more about permission schemes.

Administration Permissions

Manage Issue Layouts

This permission allows people to edit issue layouts in their company-managed project. This is an ability that all Jira Admins have by default, but can also be delegated to any user or role, allowing teams to directly manage and add fields (including existing global custom fields) to their project’s issue layouts.

To grant this permission, the screen underlying the issue layout must not be shared with other projects. To see if the screen associated with the issue layout is shared:

1. Go to the issue layout tab in the project settings of the relevant company-managed project

2. Click on the screen listed underneath the issue layout you are evaluating

3. At the top-left of the screen, the count of projects using this screen will be displayed. If the count is greater than 1, that means this screen is shared

Edit Workflows

This permission allows users to make modifications (e.g changing statuses and transitions) to exisiting isolated workflows in their company-managed project. This is an ability that all Jira Admins have by default, but can also be delegated to any user or role, allowing teams to directly manage and customise their project’s workflows.

To grant this permission, the workflow must not be shared with other projects. To see if the workflow is shared:

• From global settings (Jira Admins only):

  1. Go to Settings () > Issues

  2. Click on the Workflows tab

  3. Look at the workflow you are evaluating. If there is more than one project or workflow scheme listed next to the workflow, it is a shared workflow.

• From project settings:

  1. Go to the settings of the CMP project where the workflow is used

  2. Click on the Workflows tab

  3. Look at the workflow you are evaluating. If the count of projects listed underneath the workflow is greater than one, it is a shared workflow.

Project permissions

The following permissions define access to functionality within your company-managed projects and the issues those projects contain. They don’t define access or permissions to your Jira site, generally. Only site admins can grant people access to your Jira site. Learn more about giving people access to your Atlassian products.

Administer Projects

This permission allows people access to your project’s settings.

They can: 

• edit project role membership 

• edit project components, 

• edit project versions,

• edit some project details – project name, URL, project lead, and project description

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Typically, system administrators need this permission to help you configure projects. For that reason, they don't need product access and won't take a seat in your site’s plan.

Browse Projects

This permission allows people to view the project in the Projects directory, and view individual issues in the project and while searching Jira (except issues that have been restricted via issue-level security).

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

View aggregated data 

This permission will enable insights on the Board, Backlog, and Deployments view. Over time, this permission may allow users to view other aggregated data sources, surfaced by JQL results, queries, or reports.

• A project’s average estimations or issue count. This means a user can see how much effort has been planned all up, even if they can’t see the estimated effort for every issue.

• The names of your issue types. Even if a user doesn’t have access to a specific issue type, if it’s one of the top five issue types in a sprint, its name will appear in your insights.

• The name of your epics. Although some issues may be hidden by your issue-level security, the epics they’re linked to can be shown on the board or through the cycle time report.

• A team’s cycle time or deployment frequency. An issue/s typically hidden by issue-level security will be exposed, allowing a user to manually calculate these metrics.

Disabling the View aggregated data permission will prevent users from viewing any aggregated data backed by this permission.

This includes insights on your Board, Backlog, and Deployments view, and some reports. In the future, this may include JQL and search results.

Manage sprints

This permission allows people to create, start, and complete sprints in your project. This includes adjusting the sprint duration and goal.

This permission depends on product access to Jira. Learn more about giving people access to your Atlassian products.

Sprints are a concept from agile methodology, specifically a way of working called Scrum. Typically, sprints are managed by team leaders or designated Scrum masters. Learn more about sprints, Scrum, and how to practice agile methods in Jira.

Depending on the complexity of your board's filter query, you may need further consideration when configuring the Manage sprints permission for users. For example, if a board contains sprints from multiple projects (including service projects), users need the Manage sprints permission in every project to successfully complete sprints. For more information on the impact of complex filters, and ways to simplify your filter query, see Using Manage Sprints permission for advanced cases.

There are some sprint actions (for example, adding issues to sprints, removing issues from sprints) that require the Schedule issues and Edit issues permissions to be successful.

Learn more about planning sprints in Jira.

View development tools

Permission to view the development panel, which provides you with just enough information to evaluate the status of an issue's build data in a connected development tool, at a glance. Learn more about the development panel.

This permission depends on product access to Jira. Learn more about giving people access to your Atlassian products.

View (read-only) workflow

This permission provides the View workflow link when viewing an issue.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Issue permissions

The following permissions are only useful to people who are able to view the project. To make these permissions meaningful, first grant users, groups, or roles the Browse Projects permission in your permission scheme.

Archive issues

This permission can be granted to any role and allows people to archive any issue in your project, which includes its associated field values and comments. This helps people clean up their projects and maintain site performance and provides an alternative to the Delete issues permission.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

More about giving people access to your Atlassian products

Assign issues

This permission allows people to change the value of the Assignee field on any of your project’s issues. It doesn’t allow people to be assigned issues (see the Assignable user permission).

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

 Learn more about giving people access to your Atlassian products.

This permission allows team members to hand over tasks at different stages of the work.

Assignable user

This permission allows people to be assigned issues, meaning their username can be used to complete the Assignee field on any of your project’s issues. It doesn’t allow people to be assign issues to other users in your site (see the Assign issues permission).

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

 Learn more about giving people access to your Atlassian products.

This permission gives people the ability work on issues. When someone is assigned an issue, we notify them to view the issue. This permission is essential for core team members on any project.

Close issues

This permission allows people to set the Resolution field to a closed state on an issue based on a the conditions of your issue's workflow.

This permission requires the Transition issues and Resolve issues to be useful.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

 Learn more about giving people access to your Atlassian products.

In Jira:

• An issue is open if its resolution field isn't set.

• An issue is closed if its resolution field has a value, for example “Fixed” or “Can't reproduce”.

There are two ways to close an issue using a condition in your workflow:

1. Set the resolution field automatically via a post function. Learn more about advanced workflow configuration.

2. Prompt the user to choose a resolution via a screen. Learn more about transition screens.

This permission is used mainly for software or service teams who use quality assurance engineers to test whether fixes work as intended. You can set your permissions to allow developers to transition an issue to a done status but keep it open. Then, only allow your tester to close the issue when they’ve verified the fix.

Create issues

This permission allows people to create issues in your project, including subtasks if you’ve enabled subtasks on your site. Learn more about subtasks.

Note that:

• When a user is granted the Create issues permission for a project, they’ll see the project on the Create issue screen, even if they don’t have the Browser Projects permission for the same project.

• Users won’t be able to add attachments to issues unless they’re also granted the Create attachments permission.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

This permission can be granted to anyone logged in to the Jira site, regardless of product access - this gives you the benefit of allowing anyone to create issues in a project. For example, you might do this to allow customers to report bugs or create feature suggestions for a product you’re developing.

However, some teams might choose to limit this permission to only their core team members, for security reasons or to maintain the cleanliness of their issue list.

Delete issues

This permission allows people to delete any issue in your project, including its associated field data, comments, and work log entries, even if the user does not have the Delete comments or Delete attachments permissions. However, the Delete issues permission doesn’t include the ability to delete individual comments or attachments.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

This permission is typically reserved for team leaders or project management roles. We don’t recommend deleting issues as a practice. Changing an issue’s status to a done-category status is a much better way of clearing up unneeded issues. Changing an issue’s status notifies the issue’s reporter, assignee, and watchers of the action your team has taken on the task.

Edit issues

This permission allows people to alter the summary and description, and change the value of fields that aren’t overridden by another permission (like the Assign issues, Modify reporters, or Schedule issues permissions). This permissions also allows people to convert issues to subtasks or vice versa. Learn more about issues and subtasks.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Open organizations encourage teams to keep each other’s work up to date by adjusting fields when viewing tasks throughout the course of their work. The ability to clarify descriptions and update fields is especially handy for team members who may review tasks during shared rituals like standup meetings, planning meetings, board grooming sessions, or project kick-off meetings. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Link issues

This permission allows people to link issues in your project to one another, or to issues in other projects on your site. To view the link properly, they need the same permission in the target project or service desk. This permission is only relevant if you’ve enable issue linking. Learn more about issue linking.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Modify reporter

This permission allows people to change the value of the default Reporter field on any of your project’s issues. The Reporter field is automatically set to the issue’s creator at the time the issue is made. This allows someone to create issues on behalf of someone else.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Move issues

This permission allows people to move an issue to another project or service project on your Jira site, or to change the issue to a different issue type (making the issue follow a different workflow).

This permission requires the Create issues permission in the target project or service desk to be useful.

Resolve issues

This permission allows people to set or clear a value on the Resolution field. It also gives people the ability to see the Fix version field for issues. It doesn’t include the ability to close an issue (see the Close issues permission).

This permission requires the Transition issues permission to be useful.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Restore archived issues

This permission can be granted to any role and allows people to restore any issue in your project, which includes its associated field values and comments. A restored issue will appear in the project, dashboard, backlog and boards, and can be edited if needed.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

More about giving people access to your Atlassian products.

Schedule issues

This permission allows people to set or modify the value of the Due date field on your project’s issues. On a company-managed Scrum or Kanban board, this permission also allows people to reorder issues (“rank”) on the board and backlog.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Set issue security

This permission allows people to set the security level of specific issues in the project, changing who can view and interact with a specific issue. This is typically reserved for project managers, administrators, or other team leaders in the project. Learn more about issue security.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Transition issues

This permission allows people to view an issue’s underlying workflow in the project and update the status of any of your project’s issues. They can move any issue through the workflow, triggering any workflow post functions that may be associated with the transition along the way. Learn more about workflows.

It doesn’t allow people to set the Resolution field or close issues in your project (see the Resolve issues and Close issues permissions).

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Voters and watchers permissions

The following permissions are only useful to people who are able to view the project. To make these permissions meaningful, first grant users, groups or roles the Browse Projects permission in your permission scheme.

Manage watcher list

This permission allows people to add or remove people from an issue’s watch list.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

View voters and watchers

This permission allows people to see who’s watching any issue in your project.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Comments permissions

The following permissions are only useful to people who are able to view the project. To make these permissions meaningful, first grant users, groups or roles the Browse Projects permission in your permission scheme.

Add comments

This permission allows people to comment on any issue in your software and business projects, or add internal notes to requests in your service projects.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, you may grant this permission to anyone logged in to your Jira site.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Note that this does not include the ability to edit or delete comments.

Delete all comments

This permission allows people to remove any comment added by anyone on any of your software or business projects' issues, or delete any internal notes (and customer comments!) added to any request in a service project. It’s a bit of a super power.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

For traceability and historical investigations, we recommend preserving all issue comments. They can help you trace how a project went, or how an interaction could be improved in the future. For that reason, you may reserve this permission for team leaders, human resource managers, or other management roles.

Delete own comments

This permission allows people to remove any comments they’ve added to any issue in your project, or any internal comment they’ve added to requests in a service project.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can comment on an issue (by having the Add comments permission) should be able to remove their own comments. This practice can help clarify work if people leave erroneous or inaccurate comments. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout an issue’s lifecycle.

Edit all comments

This permission allows people to alter the content of any comment or internal note added by anyone on any of your project’s issues.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Open organizations encourage teams to edit each other’s comments to correct minor problems like spelling errors or broken links, and generally keep the communication stream clean. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit own comments

This permission allows people to alter the content of any comments they’ve added to issues in software or business projects, or any internal comment they’ve added to requests in a service project.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can comment on an issue (by having the Add comments permission) should be able to adjust their own comments and correct minor problems like spelling errors or broken links. Organizations with strict compliance or traceability requirements may consider restricting this permission to keep an accurate historical record throughout the course of an issue’s lifecycle.

Attachments permissions

The following permissions are only useful to people who are able to view the project. To make these permissions meaningful, first grant users, groups or roles the Browse Projects permission in your permission scheme.

Create attachments

This permission allows people to attach files to any issue in your project. This permission is relevant if attachments are enabled. Learn more about attachments.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Typically, any team member or collaborator may need this permission to help describe their work. Learn more about attaching files and screenshots to issues.

Delete all attachments

This permission allows people to remove any attachments added by anyone on any of your project’s issues.

This permission may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

While some teams may reserve this permission for management roles, open organizations can benefit from granting this power to autonomous team members. For example, if the issue requires images from a designer to help describe the work, it might be beneficial for team members to keep attachments up to date, even if they aren’t the owner of the original attachment.

Delete own attachments

This permission allows people to remove any file or image they attached to any issue in your project.

This permission doesn’t depend on specific product access to be useful. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can attach files to an issue (by having the Add attachments permission) should be able to remove their own attachments. This practice can help clarify work where many versions of a file or image are uploaded throughout the course of working on the issue. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout an issue’s lifecycle.

Time tracking permissions

The following permissions are only useful to people who are able to view the project. To make these permissions meaningful, first grant users, groups or roles the Browse Projects permission in your permission scheme.

The following permissions are only useful if you’ve enabled time tracking on your Jira site. Learn more about time tracking.

The following permissions may depend on product access to be useful:

• In software projects, people must have product access to Jira to use this permission.

• In service projects, people must have product access to Jira Service Management to use this permission.

• In business projects, you may grant this permission to anyone logged in to your Jira site.

Learn more about giving people access to your Atlassian products.

Work on issues

This permission allows people to interact with the time tracking field on any of your project’s issues.

This permission allows people to create a work log entry, where they can indicate the time spent and time remaining to complete the task, including a brief description of the work they did along the way.

Delete all worklogs

This permission allows people to remove any work log entry added by anyone on any of your project’s issues.

Typically, removing other people’s work log entries is a permission reserved for team leaders or other management roles.

Delete own worklogs

This permission allows people to remove the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your project’s issues.

Typically, people who actively work and log time in your project need to delete their own work logs in case of data entry errors.

Edit all worklogs

This permission allows people to alter the time logged, time remaining, and description of any work log entry added by anyone on any of your project’s issues.

Typically, adjusting other people’s work log entries is a permission reserved for team leaders or other management roles.

Edit own worklogs

This permission allows people to alter the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your project’s issues.

Typically, people who actively work and log time in your project will need to adjust their own work logs in case of data entry errors or changes to the work’s scope or requirements.