Jira Roles and Permissions: The Complete Guide to Managing User Access and Project Security

How Jira permissions work (and why it matters)

• Jira’s permission model is layered: global (whole instance), project (via schemes), and issue-level (via security).
• Use project roles to manage access cleanly, and know that company-managed projects offer more control than team-managed ones.

Jira permissions come in three layers: global, project, and issue-level. Global permissions apply across the whole Jira instance and control things like user management, dashboard access, and administrative settings. These are assigned to groups and should be kept tightly controlled.

Project permissions are managed through permission schemes, which connect actions (like editing or transitioning issues) to project roles (like Developer, QA Lead, or Client). You assign users to those roles per project.

At the most granular level, issue security schemes restrict access to specific issues regardless of project-level settings. These are useful for sensitive work, like legal or HR.

It’s also important to know the difference between company-managed and team-managed projects: 

• Company-managed projects offer more control and consistency, ideal for teams that need shared workflows, standardized permissions, and centralized configuration. For example, if your organization runs multiple software development teams that follow the same release process and need oversight from engineering leads or QA managers, company-managed projects let you enforce consistent rules across all teams.
• Team-managed projects are simpler and self-contained, great for smaller teams that don’t need centralized oversight. For instance, a marketing team running short-term campaign work may prefer a team-managed project because it lets them create and modify workflows without waiting on a Jira admin, offering more autonomy and speed.

Setting up roles and permissions the right way

Let’s say you’ve got a product team working with developers, QA leads, a designer, and a couple of contractors. Instead of assigning access to one user at a time, define project roles, such as “Developer,” “QA Lead,” and “Client.”

Then, use a permission scheme to assign actions like Browse Projects, Edit Issues, or Manage Sprints to each role.

This lets you scale easily. When someone joins the QA team, just assign them to the QA Lead role; no need to adjust permissions.

Also, know the difference between a project administrator (who can manage settings, workflows, and users) and a project lead (used for notifications and defaults). They serve different purposes, and assigning both to the same person is common, but not required.

Avoid assigning permissions directly to individual users unless necessary. Role-based control is easier to manage and audit over time.

Global permissions, admin roles, and Jira-wide settings

Global permissions affect everything in Jira; reserve them for trusted admins.

• Know the difference between Jira Admin and System Admin, and be deliberate about who can change dashboards, groups, and users.

Global permissions give users access to the entire Jira instance. The two key roles here are Jira Administrator and Jira System Administrator. Atlassian describes the differences here, but in short: system admins can manage users, apps, and infrastructure settings, while Jira admins focus on projects and configurations.

Other global permissions include:

• Browse Users and Groups (affects assignee and mention functionality)
• Manage Group Filter Subscriptions (for shared dashboards and reporting)
• Share Dashboards and Filters (controls visibility across teams)

Integrations with tools like Confluence or Jira Service Management can be affected if global permissions aren’t aligned. Keep your list of global admins small, review it regularly, and rely on Atlassian’s documentation when assigning permissions.

Putting Jira permissions into practice

This is where it gets real. Permissions aren’t just about settings; they shape how teams collaborate.

• Workflow transitions: Maybe only QA leads should move an issue into “Ready for Release.” You can enforce that by adding a workflow condition that restricts that transition to the QA Lead role. That one rule prevents dozens of accidental releases.
• Subtask control: Say a designer is working inside a developer’s story. You might allow only the “Design” role to manage their subtasks, while the developer owns the main task.
• Automation: Jira’s rules can assign roles, trigger notifications, or change issue fields, all based on events like transitions or labels. Because automation respects permission schemes, it keeps your structure clean.
• Sprint permissions: For agile teams managing sprints, permissions define who can start, complete, or edit a sprint. If you’ve ever had a sprint closed early by mistake, you know how important this is.
• Troubleshooting access: If users ever say, “I can’t see the issue,” or “I can’t transition this ticket,” it’s usually a sign of misaligned permission schemes, unassigned project roles, or conflicts with issue security levels. Use the Permission Helper in Jira to quickly diagnose the cause and fix it.

When Jira permissions aren’t enough to guide the work

Jira gives you control over permissions, transitions, and workflows, but when teams need to follow repeatable steps inside an issue, it can fall short. You might need to enforce internal checklists, repeat onboarding tasks, or structure feature requests. 

That’s where tools like Smart Checklist and Smart Templates become useful.

Smart Checklist lets you add structured, interactive checklists directly into Jira issues. Teams use it to standardize QA procedures, break down definitions of done, or document multi-step reviews, all without relying on subtasks or external docs. With Smart Checklist, you can set up custom permissions so only the right people can view, edit, or complete checklist items. This gives teams more flexibility and control without adding complexity.

Smart Templates make it easier to reuse work structures. For example, you can build a template that includes tasks for a feature rollout, like stakeholder review, design handoff, testing prep, and apply it to any new issue with a click. It saves time and ensures consistency, especially across large or distributed teams. Smart Templates work within Jira’s default global permissions, so every template you create automatically respects your organization’s existing security setup.

Note

TitanApps has launched a Trust Center, where you can check how our solutions handle security, compliance, and data protection – all in one place. This information covers all TitanApps products – in particular, Smart Checklist for Jira, Smart Templates, and Smart Hierarchy. Explore our Trust Center to learn more.

Together, these tools help teams turn scattered tribal knowledge into shared, actionable processes without breaking Jira’s permission model or cluttering up boards.

If you want to learn more, read the full Jira roles permissions guide originally written by Yuliia Tkachenko and published on the TitanApps blog.