Request Access to a Work Item in Jira Cloud – A Great Step Forward, with One Key Improvement Needed

[Sami Shaik]

Atlassian continues to deliver meaningful improvements to the Jira Cloud experience. The recently introduced Request Access When You Can't View a Work Item feature represents a welcome addition - particularly for organizations operating with strict permission models and robust security controls.

This feature addresses a long-standing usability gap. Previously, users encountering a link to a work item they couldn't access would face a dead end, often resorting to Slack messages, emails, or guesswork to resolve the issue. Now, users can request access directly from the point where the problem occurs a far more streamlined experience.

This is a strong step in the right direction, and Atlassian deserves recognition for addressing this need.

---

What the Feature Does Well

For End Users

When a user opens a work item they lack permission to view, Jira now provides a clear and actionable path forward:

1. Open the work item you don't have access to
2. Select Request access on the "You don't have access to this work item" screen
3. Receive confirmation that the request has been sent to project administrators

The workflow is simple, intuitive, and removes friction from daily collaboration.

For Project Administrators

Administrators can efficiently review and act on access requests through a centralized interface:

• Navigate to Project settings
• Select People (for company-managed projects) or Access (for team-managed projects)
• Open Access requests
• Review the request and assign the appropriate project role

This approach centralizes access management and eliminates the need for scattered approvals across multiple communication channels.

---

⚠️ The Current Limitation: Missing Work Item Context

While the feature delivers substantial value, there is one critical limitation that significantly impacts its effectiveness, particularly in large-scale or highly regulated environments.

What's Missing Today

When an administrator receives an access request, the notification indicates only that access to the project has been requested. It does not specify which work item (issue key) the user originally attempted to access.

This creates ambiguity for administrators:

• Did the user need access to a single work item, or do they require full project access?
• Is this a one-off exception or an indicator of broader access requirements?
• What level of permission is truly appropriate for this request?

The resulting challenges include:

• Over-provisioning of access - granting broader permissions than necessary
• Increased administrative overhead - back-and-forth communication with requesters
• Delayed approvals - extended resolution times for straightforward requests
• Weakened permission governance - reduced confidence in access control decisions

---

Suggested Enhancement: Include Work Item Context in Access Requests

To make this feature truly enterprise-ready, incorporating work item context into access requests would be highly valuable.

Recommended Enhancements

When a user submits an access request, Jira should capture and display:

• Work item key (e.g., PROJ-999)
• Work item summary
• Direct link to the work item
• Request type indicator - distinguishing between requests for a specific work item versus general project access

This information should be visible in two locations:

1. The Access requests page within Project settings
2. Email notifications sent to project administrators

---

Why This Enhancement Matters

Adding work item visibility to access requests would deliver meaningful benefits:

• Enables the principle of least privilege - administrators can grant precisely the access required
• Accelerates decision-making - clear context reduces the need for additional investigation
• Reduces administrative burden - fewer follow-up conversations with requesters
• Strengthens security posture - improved audit readiness and access control documentation
• Aligns with enterprise requirements - supports how Jira is used in large-scale, regulated environments

---

A Constructive Recommendation to Atlassian

The Request Access feature is already a meaningful usability improvement. With the addition of work item context-specifically identifying which issue triggered the request-it could evolve into a best-in-class access governance capability within Jira Cloud.

I encourage Atlassian to consider this enhancement, as it would benefit both administrators and end users across organizations of all sizes.

Thank you to the Atlassian team for continuously listening to community feedback and improving Jira Cloud. The commitment to iterative improvement is evident, and I look forward to seeing how this feature evolves.

Updated Post:

Please watch, vote & comment the feature request 

JRACLOUD-97042 

[Josh]

@Sami Shaik great article and suggestions! I'd also love to see a way to toggle on / off this functionality at the space level. There are some spaces where we get lots of requests but have no intentions of granting access due to internal policies.

If you haven't done so already, I'd recommend creating an Atlassian Support ticket with a link to this page and requesting that they create a proper JAC (jira.atlassian.com) feature request on your behalf.

[Sami Shaik]

@Josh 

Thanks for the comment. 

I have reached out to the Atlassian support and the following is the response from them.

Regarding the toggle ON/OFF feature: (About to release globally)

Missing Work item context in access request:

Kindly watch, vote & comment for the feature request 

JRACLOUD-97042 

[Josh]

Thanks so much for sharing, @Sami Shaik !

[Alex Hall]

A+ write up! I have shared similar questions and concerns yet didn't take the time to present them in any meaningful way.

Sometimes it feels like a black hole trying to get Atlassian to listen. I hope they take this request very seriously and see it thru.

[Sami Shaik]

Thanks for the comment.

Kindly watch, vote & comment the feature request 

JRACLOUD-97042 

[David Cowley]

For the benefit of the group, we logged a support request about this to see if we could get it turned off or a real feature request created for that functionality. Support was able to disable it for us for our site. We had a few false starts though as there are plenty of features that generate administrative noise. The feature name is apparently: Request Access for Work Items. So if you want to communicate with support I'd recommend you use that terminology.

We also received the following information:

[...]the team in charge is currently working on the toggle setting so that admins can disable the feature themselves. We plan to roll out the toggle by the end of December, approximately.

[Sami Shaik]

Please watch, vote & comment the feature request 

JRACLOUD-97042 

[Darryl Lee]

OOOF, I totally missed this. Thank you @David Cowley ! I've tagged you over in JRACLOUD-96273 - Ability to restrict users from requesting access to projects.

Betcha anything that the team working on the toggle isn't aware there's a public JAC for the thing they're supposedly doing. :-D

[Darryl Lee]

So... this feature was buried in a Bundled Release Track Notes for the Nov 11, 2025 release under Jira Product Discovery, so I completely missed it:

So I guess it's appropriate that having recently started a trial of JPD, we WEIRDLY started getting a ton of requests for it, including from external users that were no longer (or in some cases never) active on our site.

What in the world?

Support tracked it down part of the problem, which was that when we enabled fired up JPD, it automatically set the App access setting for Any domain to be User with Admin approval required. Uggggh, seriously guys?

BUT WAIT IT GETS BETTER/WORSE!

Turns out that this new feature has an odd bug. I reached out to one of the external users that generated a JPD request that we admins received.

He used to work with us, and was recently forwarded a ticket from a colleague. Because he did not have current access, he saw a screenshot like this:

So, of course, he clicked the button. But because we only allow access requests for JPD, it sent us a request for that instead of for Jira.

So ok, we switched the App access setting to None for JPD, and that should take care of things.

But it does bring to light an important point that @Sascha Weber (I hope this is the same one) brought up in JRACLOUD-96273 - Ability to restrict users from requesting access to projects 

We have been using Jira and Confluence since 2011 with a strict, role-based access model:

...

Access is managed through a Identity Management System:

• Users request access via a self-service portal.
• Approvals follow a controlled workflow and get directed to the Owners
• Intercompany changes automatically adjust permissions.

This new feature bypasses our governance process, allowing individual users to gain direct access outside IDM. It undermines:

• Compliance and auditability
• Automated role adjustments during organizational changes
• Our ability to maintain clean, group-based permissions at scale
• Trust and reliability of permission management on a user-level base

With hundreds of projects and spaces, manually removing direct user access is not feasible and would destroy user acceptance.

Our request: Please provide a way to disable the "Approve Access" feature in Jira and Confluence immediately. If this requires enabling a hidden or beta setting, we are ready to proceed.

So going beyond @Sami Shaik 's request to "improve" this feature, we'd like the option to disable it completely.