permissions will be limited to 50 grants

[Audra Bonacki]

Got this message on JIRA cloud, permissions will be limited to 50 grants. What does that mean exactly? I clicked to optimize but its just sat for days never returning a result. Help!

[Nikola Perisic]

Hi @Audra Bonacki 

You can find the updates about this here: https://support.atlassian.com/jira-cloud-administration/docs/data-limits-and-guardrails/

[Marc -Devoteam-]

Hi @Audra Bonacki 

In short it means that per permission in a permission scheme the max of combined roles, groups and users can be 50 per each specific permission in a permission scheme.

[Charlie Misonne]

Which is a lot in my opinion 😄

[Marc -Devoteam-]

I have never seen an instance where a single permisson has so many different roles, groups or users.

[Arkadiusz Wroblewski]

@Marc -Devoteam- 

Haha Marc somebody "Always" makes this first precedenso and go for Guiness :) ;D

[Abaho Katabarwa _Katabarwa Labs_]

[@mention Audra Bonacki here]

The answers above cover what the limit is: at most 50 grantees (users, groups, and roles combined) on any single permission inside a permission scheme. The part nobody has touched is the practical one: when the optimize button hangs, you are left doing the reduction by hand, and the risk is deleting a grant somebody actually depends on.

The safe order of operations: first convert direct user grants into group or role grants, since single users are almost always what pushes a permission past 50. Second, remove grants that are redundant, meaning everyone they cover already gets the same permission through another grant on that row. The hard part is proving redundancy before you delete, because Jira has no view that shows which grant path each user actually relies on.

Full disclosure, I work for Katabarwa Labs and we build an app for exactly that missing view. Access Governance Reporter maps effective access per user: every project and permission they hold, and the exact group, role, or direct grant behind it. Before you prune a grant, you can check who relies on it and via which path, and export the whole matrix as CSV for a before-and-after record. It runs entirely on Atlassian Forge inside your own tenant, no data egress.

Marketplace: Access Governance Reporter

If your cleanup needs a different cut of the data, tell us what would help and we will build it.

[MeghnaP_LogicLemur Labs]

@Audra Bonacki 

This is not a limit of 50 users in Jira.

The new limit is 50 users, space roles, or groups per permission.

For example, if a permission currently has:

• 20 users

• 15 groups

• 15 space roles

that permission has reached the 50-grant limit.

Atlassian is introducing this as part of the new Jira Cloud data limits coming in September 2026. The full list of upcoming limits is covered in this article: Jira Data Limits Are Changing in September 2026: What Every Jira Standard Admin Needs to Know.

The official Atlassian documentation confirms that the Permission Grants limit is 50 users/space roles/groups per permission, and recommends removing redundant or non-relevant grants when a permission is approaching or breaching the limit.

For admins managing a large Jira environment, I think the bigger challenge is knowing where you stand before you hit one of these limits.

This is where tools like QuotaWatch can be useful. Instead of discovering a limit only when Jira blocks a configuration change, you can keep visibility into your Jira limits and identify areas that may need attention.

So the practical takeaway is:

50 permission grants per permission ≠ 50 users in Jira.

It is a configuration limit, and with the September changes approaching, it's worth auditing your permission schemes now rather than discovering the problem during an important admin change.

[Arkadiusz Wroblewski]

It makes sense. Permissions should be simplified wherever possible, and changes like this can actually have a positive effect by pushing admins and stakeholders to review what they really need instead of just carrying old permissions forward. 😉🤠