Tools for Jira
Tools for monday.com
If you’ve ever tried to troubleshoot why someone can’t transition an issue, or worse, why someone closed an issue they never should have touched, you already know that Jira permissions aren’t just a background configuration. They shape how your teams collaborate, what people see, and who has the power to move work forward.
This guide is for anyone setting up Jira from scratch, cleaning up a messy instance, or just making sure your permission model supports how your teams work. We’ll walk through global permissions, project roles, permission schemes, real-world workflows, and how some add-ons fit into the picture.
How Jira permissions work (and why it matters)
TL;DR:
- 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
TL;DR:
- 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.
Together, these tools help teams turn scattered tribal knowledge into shared, actionable processes without breaking Jira’s permission model or cluttering up boards.
Best practices for permission management at scale
If you’re managing dozens of projects, your permission strategy needs structure.
- Standard permissions: Start by creating standard permission schemes for project types, one for engineering, another for operations, maybe one for internal tools. This keeps things consistent and easier to manage.
- Security schemes: Use issue security schemes to limit access to sensitive work, like finance or HR tickets. They allow you to control visibility beyond just the project level.
- Permission audits: Review permissions on a regular schedule. Jira’s built-in Permission Helper, or tools like ScriptRunner, can help you audit who has access to what.
- Naming consistency: Stick to consistent naming conventions for roles and groups. “Dev Team,” “Developer,” and “Engineering” shouldn’t all exist in parallel.
- External integrations: If your Jira instance is integrated with external systems like Microsoft Teams, Azure Active Directory, or third-party SSO tools, remember that permission conflicts can still occur. For example, someone may be provisioned at the identity layer but lack project-level access. Keep internal roles and integrations aligned.
- Admin control: Finally, keep your list of global admins small. The more people with full control, the greater your risk of misconfiguration and the harder it is to trace errors.
With the right setup, Jira’s permission model gives you control without complexity. By combining structured roles, clear schemes, and purpose-built tools like Smart Checklist and Smart Templates, you can turn scattered processes into consistent workflows and keep teams aligned, accountable, and moving forward. Best of luck!
