Help us decide which space settings your team members should see

July 14, 2026

Hi Jira admins! 👋

I'm Carol, a Product Manager on the Jira Configuration team. I'm working on something I think you'll have strong opinions about: should your team members be able to see space settings?

The problem we're trying to solve

Today, space settings are completely hidden from non-admin users. If a team member wants to know what fields are configured, how the workflow works, or who has what project role, they have to ask you. We hear from admins that answering these kinds of informational questions is a real time sink.

We're exploring giving team members read-only visibility into certain settings pages, so they can self-serve answers without needing to come to you. But we want to get the boundaries right: which settings should be visible, which should stay admin-only, and are there things you'd actively want to keep hidden?

What's involved

A 30-minute video call (Zoom) with me

There's a short card-sorting exercise where you'll tell us which settings pages you'd open up, which you'd keep restricted, and why.

Your feedback will directly influence what we build and in what order

Who we're looking for

Jira Cloud admins

Keen to chat?

Apply here: https://www.userinterviews.com/projects/8YKgYlBW6g/apply

Regards

Carol

13 comments

Hi @Carol Low

I stopped reading when there was the question should users have access to space settings. My opinion is no, this would break the governance and the authorization of which user should do what.

Like • like this

I think this depends on whether we are talking about Team Managed or Company Managed spaces.

For Team Managed, you can give everyone access to anything, as far as I am concerned, as those are playboxes for companies that don't care about structure and governance. They are Team Managed after all and not of concern to anyone else outside the team as I see it.

For Company Managed, I have never in 14 years heard a team being interested in what the name of a workflow is or what configuration a space has, so maybe that is very specific to some areas or industries I have yet to explore?

If it is something that customers find to be important, then I guess you could have a similar view as the Summary combined with a User tab that shows users and roles. The Users and Roles could be a good idea because then you can also provide information on what each role provides in that space, which sometimes is not 100% clear in companies that do not have structure and governance.

This does sound more like an organization issue than a tool issue, but if you want to spend some time on this, I would say a read-only Summary and People tab in the overview section can work.

Like • like this

Hi @Carol Low ,

I option always I and my users want to see are, the project roles/users/groups in the project. So that they need not come to Jira admins asking why I cannot assign work item to so and so, why user cannot view my work items created etc.

Like • like this

@Carol Low

I would like Jira Users to be able to see:

Space owner
Space Administrator(s)
Board Administrator(s)

so they know who to contact in case of questions about the space, rather than submitting an internal support request for the Jira Administrator to handle information/access requests that a Space/Board Admin is able to handle.

Like • like this

I'd go with these pages:

"Details", "Summary", "People", "Versions", "Releases" and "Development Tools"

I was gonna say "Permissions" and "Notifications" too at first but then I figured that that might raise more questions than it'd answer.

As for Workflows ... well they are visible per work item but not as an overview over all issue types. So I'd vote for that to be visible - furthermore, I'd like users be able to see what might restrict a transition (that's a question I see commonly). I am not sure, if that is the correct place for that, though (+ if users would understand).

Thanks for taking the time to listen and read

---

PS:

I hope, that I don't strive too much but will there be a similar quiestionaire for space permissions? Because I hate to give away "Space Admin" but I have do because of things like "Components", "Development Tools" and adding Boards.

---

Like • like this

like @Dave Mathijs said I'd definitely like users to see who owns the space/project, project roles, board admins, workflows (read-only), and configured fields. Those are the questions admins answer over and over.

What I'd keep hidden are implementation details like permission schemes, notification schemes, automation rules, and other global configuration that mostly create confusion without helping users.

A "Why can't I do this?" view for workflow transitions (e.g. required role or condition) would probably reduce support requests even more than exposing the raw configuration.

Like • like this

Allow granting read-only to everything. People overthink Jira way too much. There's no harm, therefore no foul.

Like • Suresh likes this

I would like to have permissions for Automation, Components and Forms broken out like Releases was. It would be nice if the users who had the View Read Only workflow permission could see the Workflows page in the settings. We've had people ask for screenshots of the workflows because the only way they can see them is by clicking into an item and viewing it there. It's cumbersome for a project lead to review workflows like that. We only use company managed spaces and it can be cumbersome for users to submit requests for automation, forms and components when it's something they should be able to manage on their own.

The reason we don't allow admins outside of the admin team is because we found users began adding people individually even if they didn't have a license. Our company uses security groups for permissions so we frowned upon that and took away admin for everyone.

Like • like this

I'm aligned with Becker_Rene's response. Those seem like the appropriate elements we'd want users to be able to self-serve from a questions/answers perspective. Anything beyond that prompts more problems than this would potentially solve.

I'd like for users to be able to view the Space Admin and Space owner. I think the left side of the Summary (metrics) page for the space is a great place for this info.

And, users should be able to Ask Rovo to identify the Space Admin or Space owner for any space, even if the user is not yet a member of the space.

Granting users permissions doesn't always solve their problems if they don't know what to do with them.

In the AI era, Atlassian Rovo should step in to help users understand why they are experiencing an issue and how to resolve it.

For example: If someone shares a ticket link that I can't access, I shouldn't have to guess my project role or dig through permission schemes to see what's blocking me. Instead, when I try to view, comment on, or link to ticket XYZ-123, Rovo should proactively tell me exactly which permission is missing and say: "You need Permission X. Please reach out to John Doe (Project Admin) to get this sorted."

Like • Apryl Harris likes this

@joao zampa
Rovo does exactly what you suggested to some degree.

I've seen in one real use case where a leader tried to identify details such as license count and Rovo informed the user he did not have the proper permissions and to ask me (by name). I'm one of the org's Jira Admin (org and site admin).

I must say I am a bit surprised how many seem to work in Jira spaces, they have no idea who is running it, and where they have never been introduced to it by someone?

I guess the old "If you don't know who you are working with and why, then you are in the wrong place" is not always the case out there?

As a team member, you should never have any reason to ask about configurations or who is in charge. If you don't know who is in charge of your Jira Space, then it is not defined or set up properly. If clarity is not built into the platform, what are you even doing?

If something is not configured the way you think it should be, then you bring it up with the team, discuss it, and then decide if you want to change it. The people in charge will either make the changes or request them from the ones who make the changes.

If some lack permissions, then they tell the people in charge that, and they will fix it. If you have made the permissions so complicated you don't understand what a role does or have documentation on how roles affect workflows and so on, then you are doing it wrong... Right?

If someone shares a ticket that you can't access, that person made a mistake and needs to learn not to do that in the future. Access is there for a reason, and if you are working in a space and don't know what you can and can not do with your work tool, then you have not been introduced or trained properly.

I get it if someone is directed to some mysterious space and they want to know who is behind that space, so having Space Owner listed in the overview, for example, makes sense.

Providing access to configuration data that someone malicious can use to harm spaces is not a good idea. Providing, for example, the name of a workflow or permission scheme will mean absolutely nothing to the users, so the question is what problems are we really trying to solve?

Shut nosy people up so they stop asking us for information they don't need, or are we talking about tools to help understand why a person is restricted from doing certain things or adding public ownership information to spaces (which tend to be broken when people leave a lot more than we care to admit?)