keelapps/Guides

Which Jira projects can a group access?

Jira Cloud · Updated 7 October 2026

Jira Cloud tells you who is in a group. It does not tell you which projects the group can reach. This guide shows how to work it out with the REST API, the four traps that make hand-rolled checks quietly wrong, and what else to check before you delete a group.

We make AccessLens, one of the ways to do this, so we are not neutral. The manual procedure comes first and works without any app.

The question Jira can’t answer

An admin finds a group called contractors-2023 and wants to delete it. Or an auditor asks which projects the Finance group can see. Jira is organised the other way round: open a project and it shows who can reach it. There is no view that starts from the group.

The request for one, JRACLOUD-71967, has been open since 2019 with about a thousand votes. The knowledge base article most people find is a set of SQL queries, and those only work on Data Center.

Why checking permission schemes is not enough

Access to a project comes through two layers:

• The permission scheme says who holds each permission. That can be a group, but in most schemes it is a project role such as Administrators or Developers.
• Each project then says who is in each role. Groups are added there, one project at a time.

So a group that appears in no permission scheme can still reach forty projects through their roles. Searching schemes for the group’s name finds the rare case and misses the common one.

A procedure you can run today

1. List the schemes with their grants: GET /rest/api/3/permissionscheme?expand=permissions,group. Note every scheme where the holder is your group.
2. Map schemes to projects with GET /rest/api/3/project/{key}/permissionscheme for each project. One shared scheme can stand behind dozens of projects.
3. For every project, list its roles with GET /rest/api/3/project/{key}/role, follow each role’s URL, and look for your group among the actors (atlassian-group-role-actor).
4. For each role the group holds, go back to that project’s scheme and see what the role is actually granted. Being in a role the scheme grants nothing to is not access.
5. Write down the date. The answer is only true as of when you ran it.

If steps 1 and 3 come back empty for every project, no project grants anything to that group.

Four traps

1. Roles and scheme grants are different layers. This is the one that catches most scripts, as above.
2. Shared schemes. One grant in one scheme can mean access to every project that uses it. Count projects, not schemes.
3. Grants that name nobody. “Any logged-in user” and “Public” give access without mentioning your group. Deleting the group changes nothing for those projects, and an auditor will care more about them than about the group.
4. The answer has no memory. Run it today and you know today. “Who could reach this project on 30 June” cannot be rebuilt afterwards unless you kept the result at the time. Jira’s audit log keeps events for 180 days and never records who held access on a given day.

What else a group can be wired into

Project permissions are only part of “is it safe to delete”. Before removing a group, also check:

• product access and global permissions;
• filter and dashboard shares, and board administrators;
• issue security levels and notification schemes;
• workflow conditions and validators that test group membership;
• automation rules;
• Confluence space permissions and page restrictions, if the group is shared.

None of these show up in the procedure above.

For SOC 2 and ISO 27001 access reviews

A periodic access review asks the same question at a fixed date and wants proof that someone looked. Three things make the evidence hold up:

• A dated record of who could reach what, kept as it was on the review date, not regenerated later.
• The change since the last review: what was granted and what was revoked between the two dates.
• A sign-off tied to that record: who reviewed it, when, and what they decided.

The procedure above gives you the first one if you save its output each quarter. The other two are a spreadsheet and a ticket, kept together.

Where AccessLens fits

AccessLens for Jira runs steps 1 to 4 for the whole site and stores the result as a dated snapshot. Explore → By group lists every project the group can reach and whether that comes from a scheme grant or a role, with nested group membership expanded. Because every answer comes from a snapshot, you can compare two quarters and sign off a review against the snapshot it was decided on.

What it does not do: it reads project permission schemes and roles only, so the list in the previous section is still yours to check, and archived projects are not scanned. It runs on Atlassian Forge with no external calls, and it is free for sites of up to 10 users.

Try AccessLens free

On Confluence the same question is about spaces and restricted pages: AccessLens for Confluence.