What is a Jira permission scheme?

A permission scheme is a named, reusable set of rules mapping each Jira permission (like Browse Projects, Create Issues, or Administer Projects) to who holds it — specific users, groups, or project roles. You attach a scheme to a project, and it governs what people can do there. Multiple projects can share one scheme, which is why they're reusable rather than per-project.

Why can everyone in my company see my Jira project?

Almost always because the Browse Projects permission is granted to 'Any logged-in user' (sometimes shown as 'Application access' or 'Any logged in user'). That default means every licensed user in your instance can view the project. Restrict Browse Projects to a specific role or group and the leak stops.

What's the difference between a group and a project role in Jira?

A group is instance-wide — the same membership everywhere. A project role is scoped per project, so the same role (like 'Client' or 'Developer') can contain different people in different projects. Roles are usually the better tool for permission schemes because one shared scheme can behave differently per project depending on who's in each role.

How do I restrict a Jira project to just a few people?

Set the project's permission scheme so Browse Projects (and any other sensitive permissions) is granted to a specific project role or group rather than 'Any logged-in user,' then add only the intended people to that role or group. Check the Browse Projects permission first — it's the one that controls visibility.

Jira permission schemes explained (without the headache)

Permission schemes are where a lot of people decide Jira administration is not for them. The screen is dense, the words overlap ("users" and "groups" and "roles" all sound like the same thing), and it's never obvious which knob does what. So people leave the defaults alone — and the defaults are exactly the problem.

Here's the whole thing in plain English, and the one setting that causes most of the trouble. (Note this is a different axis from licensing — if the question you actually have is how to get an unlicensed person into a project rather than restrict one who's already in your instance, see what Jira guest access actually offers.)

The mental model

A permission scheme is a reusable list that maps every Jira permission to whoever holds it. That's it. "Browse Projects → these people. Create Issues → these people. Administer Projects → these people." You build the list once, attach it to a project, and it governs what everyone can do there. Attach the same list to ten projects and they all behave the same way — which is the point of it being a scheme rather than a per-project setting.

So a permission scheme isn't a wall around one project. It's a template of rules you apply to many.

Three ways to say "who"

Every permission is granted to some "who," and Jira gives you three kinds, which is where the confusion starts:

Users — specific named individuals. Simple, but brittle: name people directly and you'll be editing schemes every time someone joins or leaves.

Groups — instance-wide buckets of people. The same membership everywhere in Jira. Good for broad categories ("all developers"), clumsy when you want different people per project.

Project roles — the underrated one. A role like "Client" or "Developer" exists across projects, but who's in it is set per project. So one shared scheme that grants Browse Projects to the "Client" role will show Project A to Project A's clients and Project B to Project B's clients — automatically, because each project's role membership differs.

For most situations, roles are the right tool. They let one scheme stay flexible instead of forcing a new scheme per project.

The one setting that causes most of the pain

If you've ever been surprised that everyone in your company can see a project, this is why: the Browse Projects permission, granted to "Any logged-in user."

Browse Projects is the master visibility switch — hold it, and you can see the project. And on many default schemes, it's granted to "Any logged-in user" (you may also see this as "Application access"), which means every licensed person in your entire Jira instance. Not your team. Everyone.

For an internal, open-by-default culture, that might be fine. For anything sensitive — client work, HR, security, a skunkworks project — it's a quiet leak. Nobody chose it; it's just the default nobody changed.

The fix is one change: set Browse Projects to a specific role (say, "Team") or group instead of "Any logged-in user," then make sure the right people are in that role. The moment you do, the project stops being visible to the whole company.

How to restrict a project to just a few people

Putting it together:

Find the project's permission scheme (Project settings → Permissions).
Check who holds Browse Projects. If it's "Any logged-in user," that's your leak.
Change it to a specific project role or group.
Add only the intended people to that role or group.
Scan the other sensitive permissions — Administer Projects, Delete Issues, Manage Sprints — and make sure they're not broader than you meant.

If several projects need the same rules, build one scheme and share it, using roles so each project's membership can differ. If one project is genuinely special, give it its own scheme rather than contorting a shared one.

The mistakes to avoid

Don't grant permissions to named users when a role would do — you'll drown in maintenance. Don't create a new scheme for every project out of caution — you'll end up with forty near-identical schemes nobody understands. And don't assume the defaults are safe; the "Any logged-in user" grant on Browse Projects is the single most common way private work becomes visible to a whole company.

Permission schemes aren't hard once you see the shape: a reusable list of "who can do what," best expressed with roles, and dominated by one visibility permission that ships too open. Fix that one, understand roles, and the headache is mostly gone. And if the reason you're touching permissions at all is to safely show a project to an external client rather than lock down your own team, a permission scheme edit usually isn't even the right tool — see our guide to sharing Jira status without a license for approaches that don't require reworking access for everyone else.

I'm Andrey. I build small, focused apps for Jira at Guenov Labs, and I write about the parts of Jira that are more confusing than they need to be.