JIRA Permissions and Roles
JIRA permissions determine who can see, create, edit, transition, and delete issues across the system. Without proper permission configuration, team members either see everything they should not or cannot do their job because access is blocked. A well-configured permission model protects sensitive data, maintains process integrity, and ensures every user has exactly the access they need — no more, no less. This topic covers the complete permission system in JIRA from groups and roles to permission schemes and issue security.
The Permission Hierarchy
JIRA permissions work in layers. Global permissions apply across the entire JIRA instance. Project permissions apply within a specific project. Understanding both layers is essential before configuring access.
| Layer | Scope | Who Configures It | Example Permission |
|---|---|---|---|
| Global Permissions | Entire JIRA instance | JIRA Administrator | Administer JIRA, Create Projects, Browse Users |
| Project Permissions | One specific project | JIRA Admin / Project Admin | Create Issues, Edit Issues, Transition Issues, Delete Issues |
| Issue Security | Individual issues | JIRA Admin / Project Admin | Restrict visibility of sensitive issues to specific roles only |
Global Permissions
Global permissions control what users can do at the system level — creating projects, managing users, and accessing the JIRA administration panel. Only JIRA Administrators manage these settings.
| Permission | What It Allows |
|---|---|
| Administer JIRA | Full access to all administration settings — most powerful permission |
| Browse Users and Groups | See other users in the @mention picker and user search |
| Create Shared Objects | Create dashboards and filters that can be shared with other users |
| Manage Group Filter Subscriptions | Subscribe groups to filter result emails |
| Bulk Change | Edit, move, or delete multiple issues at once |
| Use JIRA | Log in and use JIRA at all — the baseline permission every user needs |
JIRA Groups
A Group is a named collection of JIRA users. Permissions can be granted to an entire group rather than assigning permissions to each user individually. Groups simplify user management in large organizations.
| Group Name | Typical Members | Common Permissions |
|---|---|---|
| jira-administrators | JIRA Admins only | Administer JIRA, all project permissions |
| jira-software-users | All developers, PMs, QA | Use JIRA Software, access boards and backlog |
| jira-servicedesk-users | IT agents, support staff | Access Service Management agent view |
| developers | Dev team members | Create issues, transition issues, log work |
| qa-engineers | QA team members | Create bugs, transition to Done, close issues |
Project Roles
A Project Role is a named position within a specific project. Unlike groups, project roles are project-specific. Adding a user to the "Developer" role in Project A does not give them Developer permissions in Project B. This separation is critical for multi-project environments where different teams should not see each other's work.
| Role Name | Typical Permissions | Example Members |
|---|---|---|
| Administrator | All project-level permissions including delete and settings changes | Project Manager, JIRA Admin |
| Developer | Create, edit, transition, comment, log work | Developers, QA Engineers |
| Viewer | Browse issues and boards — read-only access | Stakeholders, Business Analysts, Clients |
Project Permissions
Project Permissions define what each role can do within a project. These permissions are configured through a Permission Scheme that is attached to the project.
| Permission | What It Controls |
|---|---|
| Browse Projects | See the project, its issues, and its board at all |
| Create Issues | Add new issues to the project |
| Edit Issues | Modify any field on an existing issue |
| Transition Issues | Move issues between workflow statuses |
| Delete Issues | Permanently delete an issue and all its history |
| Assign Issues | Change the assignee field on any issue |
| Assignable User | Appear in the assignee dropdown — a user must have this to be assigned issues |
| Close Issues | Move issues to the Done or Closed status |
| Resolve Issues | Set the Resolution field on an issue |
| Add Comments | Post comments on any issue |
| Edit All Comments | Modify comments written by other users |
| Delete All Comments | Remove comments written by other users |
| Log Work | Add work log entries to track time spent |
| Manage Watchers | Add or remove watchers from issues |
| Administer Project | Access Project Settings and change project configuration |
Permission Schemes
A Permission Scheme is a reusable set of permission rules. Each rule maps a permission to a role, group, or user. The scheme attaches to one or more projects. Projects sharing a scheme automatically share the same permission rules.
| Permission | Granted To |
|---|---|
| Browse Projects | Any logged-in user |
| Create Issues | Role: Developer, Role: Administrator |
| Edit Issues | Role: Developer, Role: Administrator |
| Transition Issues | Role: Developer, Role: Administrator |
| Close Issues | Role: Developer, Role: Administrator |
| Delete Issues | Role: Administrator only |
| Assign Issues | Role: Developer, Role: Administrator |
| Assignable User | Role: Developer |
| Add Comments | Any logged-in user |
| Edit All Comments | Role: Administrator only |
| Log Work | Role: Developer |
| Administer Project | Role: Administrator only |
Issue Security Schemes
Issue Security restricts the visibility of individual issues to specific roles or users — even within a project that the user can normally access. An issue with a security level set to "Management Only" becomes invisible to regular Developers browsing the project, even though they can see all other issues.
When to Use Issue Security
| Scenario | Security Level Applied To |
|---|---|
| A security vulnerability that must not be public | Security Team + Admin only |
| Salary or HR-related issues in a business project | HR Manager + Admin only |
| Client-specific feature requests | Account Manager + Client + Admin only |
| Executive-level strategic planning issues | Leadership Team + Admin only |
Groups vs Project Roles: Which to Use?
| Aspect | Groups | Project Roles |
|---|---|---|
| Scope | Global — across all projects | Local — per project |
| Who manages membership | JIRA Administrator only | Project Administrator |
| Best for | Broad access grants (all devs get base permissions) | Project-specific access (only this project's team) |
| Flexibility | Low — changes affect all projects using that group | High — each project manages its own role members |
| Recommended use | Grant global permissions (JIRA access, browse users) | Grant project permissions (create, edit, transition issues) |
Permission Troubleshooting
JIRA provides a Permission Helper tool that diagnoses permission issues. Navigate to Project Settings → Permissions → Permission Helper. Enter a username and a permission to check. JIRA explains exactly why the user has or does not have that permission — tracing it back to the specific role, group, or scheme that grants or denies it.
Summary
JIRA permissions protect data, enforce process, and ensure teams only access what they need. Global permissions control system-level access. Project permissions govern what users can do within a specific project. Groups simplify bulk permission management. Project roles provide per-project flexibility. Permission schemes attach reusable rule sets to multiple projects. Issue security adds a final layer of visibility control at the individual issue level. The Permission Helper diagnoses access problems quickly. A well-designed permission model is invisible when it works correctly — users do their jobs without friction while unauthorized actions are quietly blocked. The next important topic covers how JIRA keeps everyone informed about changes through Notifications and Email Alerts.