- \n
- Jira\u2019s permission model is layered: global (whole instance), project (via schemes), and issue-level (via security).<\/li>\n\n\n\n
- Use project roles to manage access cleanly, and know that company-managed projects offer more control than team-managed ones.<\/li>\n<\/ul>\n\n\n\n
![\"three](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2025\/08\/Infographic-2-1024x682.png\")
<\/figure>\n\n\n\nJira 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.<\/p>\n\n\n\n
Project permissions are managed through permission schemes<\/strong>, which connect actions (like editing or transitioning issues) to project roles<\/strong> (like Developer, QA Lead, or Client). You assign users to those roles per project.<\/p>\n\n\n\n
At the most granular level, issue security schemes<\/strong> restrict access to specific issues regardless of project-level settings. These are useful for sensitive work, like legal or HR.<\/p>\n\n\n\n
It\u2019s also important to know the difference between company-managed and team-managed projects: <\/p>\n\n\n\n
- \n
- Company-managed projects<\/strong> 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.<\/li>\n\n\n\n
- Team-managed projects <\/strong>are simpler and self-contained, great for smaller teams that don\u2019t 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.<\/li>\n<\/ul>\n\n\n\n
Setting up roles and permissions the right way<\/h2>\n\n\n\n
Let\u2019s say you\u2019ve 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 \u201cDeveloper,\u201d \u201cQA Lead,\u201d and \u201cClient.\u201d <\/p>\n\n\n\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2025\/08\/Template-for-UI-1-1024x673.png\")
<\/figure>\n\n\n\nThen, use a permission scheme to assign actions like Browse Projects<\/strong>, Edit Issues<\/strong>, or Manage Sprints<\/strong> to each role.<\/p>\n\n\n\n
![\"\"](\"https:\/\/titanapps.io\/blog\/wp-content\/uploads\/2025\/08\/Template-for-UI-2-1024x556.png\")
<\/figure>\n\n\n\nThis lets you scale easily. When someone joins the QA team, just assign them to the QA Lead role; no need to adjust permissions.<\/p>\n\n\n\n
Also, know the difference between a project administrator<\/strong> (who can manage settings, workflows, and users) and a project lead<\/strong> (used for notifications and defaults). They serve different purposes, and assigning both to the same person is common, but not required.<\/p>\n\n\n\n
Avoid assigning permissions directly to individual users unless necessary. Role-based control is easier to manage and audit over time.<\/p>\n\n\n\n
Global permissions, admin roles, and Jira-wide settings<\/h2>\n\n\n\n
TL;DR:<\/strong> <\/p>\n\n\n\n
- \n
- Global permissions affect everything in Jira; reserve them for trusted admins.<\/li>\n\n\n\n
- Know the difference between Jira Admin and System Admin, and be deliberate about who can change dashboards, groups, and users.<\/li>\n<\/ul>\n\n\n\n
Global permissions give users access to the entire Jira instance. The two key roles here are Jira Administrator<\/strong> and Jira System Administrator<\/strong>. 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.<\/p>\n\n\n\n
Other global permissions include:<\/p>\n\n\n\n
- \n
- Browse Users and Groups <\/strong>(affects assignee and mention functionality)<\/li>\n\n\n\n
- Manage Group Filter Subscriptions <\/strong>(for shared dashboards and reporting)<\/li>\n\n\n\n
- Share Dashboards and Filters <\/strong>(controls visibility across teams)<\/li>\n<\/ul>\n\n\n\n
Integrations with tools like Confluence or Jira Service Management<\/a> can be affected if global permissions aren\u2019t aligned. Keep your list of global admins small, review it regularly, and rely on Atlassian\u2019s documentation when assigning permissions.<\/p>\n\n\n\n
Putting Jira permissions into practice<\/h2>\n\n\n\n
This is where it gets real. Permissions aren\u2019t just about settings; they shape how teams collaborate.<\/p>\n\n\n\n
- \n
- Workflow transitions:<\/strong> Maybe only QA leads should move an issue into \u201cReady for Release.\u201d 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.<\/li>\n\n\n\n
- Subtask control:<\/strong> Say a designer is working inside a developer\u2019s story. You might allow <\/strong>only the \u201cDesign\u201d role to manage their subtasks, while the developer owns the main task.<\/li>\n\n\n\n
- Automation:<\/strong> Jira\u2019s 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.<\/li>\n\n\n\n
- Sprint permissions:<\/strong> For agile teams managing sprints, permissions define who can start, complete, or edit a sprint. If you\u2019ve ever had a sprint closed early by mistake, you know how important this is.<\/li>\n\n\n\n
- Troubleshooting access:<\/strong> If users ever say, \u201cI can\u2019t see the issue,\u201d or \u201cI can’t transition this ticket,\u201d it\u2019s 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.<\/li>\n<\/ul>\n\n\n\n
When Jira permissions aren\u2019t enough to guide the work<\/h3>\n\n\n\n
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. <\/p>\n\n\n\n
That\u2019s where tools like Smart Checklist<\/a> and Smart Templates<\/a> become useful.<\/p>\n\n\n\n
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<\/a> so only the right people can view, edit, or complete checklist items. This gives teams more flexibility and control without adding complexity.<\/p>\n\n\n\n
- Subtask control:<\/strong> Say a designer is working inside a developer\u2019s story. You might allow <\/strong>only the \u201cDesign\u201d role to manage their subtasks, while the developer owns the main task.<\/li>\n\n\n\n
- Manage Group Filter Subscriptions <\/strong>(for shared dashboards and reporting)<\/li>\n\n\n\n
- Browse Users and Groups <\/strong>(affects assignee and mention functionality)<\/li>\n\n\n\n
- Team-managed projects <\/strong>are simpler and self-contained, great for smaller teams that don\u2019t 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.<\/li>\n<\/ul>\n\n\n\n
- Company-managed projects<\/strong> 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.<\/li>\n\n\n\n