Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Tuesday Jira Vibes - Jira Permission Mistakes (and how to avoid them). What’s your suggestion?

Daria Kulikova_GitProtect_io
Community Champion
July 7, 2026

Jira Tuesday Vibes.png

Hello, New to Jira Community! 👋

In today’s Tuesday Jira Vibes (or should I say Wednesday Jira Vibes? 😅), let’s talk about something that often goes unnoticed… until it causes a headache — Jira permissions.

Permissions determine who can view, create, edit, transition, and administer work items. When they're configured correctly, they keep your projects secure while allowing your team to collaborate efficiently. But when they're not, they can create unnecessary roadblocks or even expose sensitive information.

That’s why a well-configured permission setup matters much more than many new Jira users realize.

So, what are some common permission mistakes? Or, better yet... what should you avoid doing?

🚫 Don't assign permissions to individual users.

While it may seem convenient at first, it quickly becomes difficult to manage as your team grows.

What to do instead? Assign permissions to groups or project roles. This will make onboarding, offboarding, and role changes much easier.

🚫 Don't give everyone too many permissions "just in case."

Giving broad access might seem harmless, but it increases the risk of accidental changes, deleted work items, or unauthorized access to sensitive information.

What to do instead? Follow the principle of least privilege, which maans give people only the permissions they need to do their work.

🚫 Don't ignore Project Roles.

Some Jira admins rely only on groups, which can lead to duplicate permission schemes across multiple projects.

What to do instead? Use project roles such as Administrators, Developers, and Users. They're reusable, easier to maintain, and make permission management much more scalable.

🚫 Don't set permissions once and forget about them.

Teams can change, or new projects can appear. People join, leave, or change roles. A permission scheme that worked six months ago may no longer fit your team's needs.

What to do instead? Review your permission schemes regularly to make sure they still reflect your current team structure.

Among other mistakes that came to my mind there are:

Making permissions so restrictive that people can't do their work without asking an admin.

Using different permission setups for similar projects without a clear reason.

Assuming everyone understands how permissions work (spoiler: they usually don't!).

…I'm sure there are many more.

So, let's turn this into today's discussion!

What other permission mistakes would you add to the list?

Which permission mistake have you seen most often?

Have permissions ever caused a funny or frustrating situation for your team?

If you could give one piece of advice to someone setting up Jira permissions for the first time, what would it be?

3 comments

Comment

Log in or Sign up to comment
Anahit Sukiasyan
Community Champion
July 8, 2026

Great points, @Daria Kulikova_GitProtect_io! I would also add: avoid using global permissions when space-level access is enough. Giving broader access than needed can create security risks and confusion.

A clear structure with groups, space roles, and documented rules makes Jira administration much easier in the long run.

Like # people like this
Peter_DevSamurai
Atlassian Partner
July 8, 2026

I always make this mistake 😅 Thank you for reminding me 

Like # people like this
Peter_DevSamurai
Atlassian Partner
July 8, 2026

One practical tip that I can add: don’t create a new permission scheme for every project unless necessary.

Permission schemes can be shared across projects, so keep them reusable. Use a small number of schemes, assign permissions to project roles, and manage users within those roles. This will reduce the risk of having many similar schemes that become hard to audit later.

Like # people like this
Brita Moorus
Community Champion
July 8, 2026

Great list! 👏

One mistake I’d add is forgetting the “Browse Projects” permission. It sounds basic, but it’s the gatekeeper for almost everything else - if users don’t have it, they may not see the project or work items at all, even if other permissions look correct.

Another common one: mixing groups and project roles without a clear logic. My rule is:

  • using groups for broad access, usually managed centrally

  • using project roles for project-level responsibility

  • avoiding individual users unless it's a very temporary exception

Also - always test permissions with the Permission helper before blaming Jira 😄

Like # people like this
TAGS
AUG Leaders

Atlassian Community Events