🤖 <Watch on demand> An AMA on Scaling Jira Admin - giving teams autonomy without losing control

[#1]

What if every team in your organization could work exactly the way they need to - independently, confidently, and within the standards you've set?

This live session covered scaling Jira administration and explored how Jira admins can give teams real autonomy without sacrificing consistency, governance, or trust in reporting.

This is especially relevant for admins trying to balance speed and standardization across many teams. Whether you manage Jira for 50 users or 50,000, the session is designed to show where Jira administration is heading and how to scale your impact.

Watch the session on demand below: 

[Becker_ Rene]

This may seem a bit stupid ... but where's the registration button?

When I open the page, I get a popup saying

"We’re unable to locate some information needed for this page to work. Please try again and let us know if this issue persists."

And then I will see all the pictures, description of the content ... but no way to register and/or receive an invitation file or a link to a video platform ...

Am I missing something?

Best regards

Rene

---

[Mukarramah Hamid]

Hallo sudah nonton vidionya suka

[joao zampa]

This might be a stupid question, so bear with me.

Why does Atlassian keep investing in team-managed spaces? We tried it before, and based on the mess it created, we'd be reluctant to try again.

Why not bring the same functionality to company-managed projects, that are not sharing configuration with other projects? Why can't those be treated as "team spaces" under a company-managed structure? In my view, the ability to add a new field to a company-managed project — scoped only to that project, not shared via screen schemes, should be something project admins can do themselves.

And to the broader point: what's the value of a team-managed project if we're restricting what teams can actually do with it?

The effort here is appreciated, admin overhead is a real pain for us, but what I'd really like to see is field ownership. Two examples:

• The finance team has a field embedded in all Initiatives that they use to collect data for reporting. Any time they need to change a field value, they have to come to us. Why can't we assign a field owner so the person who actually cares about the data can make changes themselves?
• A field scoped to a single project, why can't the project admin manage its values directly?

Great to see progress being made on reducing admin burden. Excited to see where this goes!

[Greg D]

joao, I have wondered the same thing. In my experience, rather than needing a fully siloed space that does its own thing under a policy, most of the need for non-app-admins tends to be around controlling the existing company managed objects within their space(s)... they want to add existing fields to all screens including create, decide fields and field values that can be set, edit workflows, etc.

We also have a lot of cases where someone is a Jira space admin for more than one space and they want the spaces to share schemes and other settings, but they want to maintain control.

It has always felt like the teams have really wanted/needed more control after starting with defaults all the way down the chain. Atlassian sets some default settings, Org Admins then further augment/refine the defaults as a good starting point, Site Admins further augment/refine from there, App Admins from there, Space Admins from there on all spaces they can admin together, then Users can control personal settings around the starting points but not much around shared configuration.

I realize I am greatly simplifying everything and there are probably technical blockers. I am also excited to see the effort in improving the Jira administration and look forward to seeing more updates in this initiative!