Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How do you spread Jira admin skills without losing control?

John Price
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 17, 2021

I manage Jira for a large org and we have Cloud (1800 users), Data Center (8000), and Server (10k+).  We have a team of 6 people that manages support, infrastructure (AWS), upgrades, and migrations.  Obviously that don't scale well and makes us a potential blocker for the very teams we want to help.  In the past we've allowed a large number of Jira admins from other teams in order to enable self-service, but those admins haven't always made good choices about customization and it's led to a bit of a mess.

I'd like to hear how other admins handle this.  Cloud has of course added self-service projects, but I'm not convinced those are 100% fully baked just yet, especially with regard to the central admin team's visibility into them.  

Some things we've done recently:

  • Require admins to read and sign a Confluence page called Jira Admin Code of Conduct.  This is a base "I know what I'm doing and will ask for help if I don't" sort of thing.
  • (Data Center) Soft barrier to custom field creation by hiding the button using CSS and encouraging admin discussion (Teams channel) about customization needs.
  • More 1-on-1 time showing teams how to solve problems as a project/Jira admin.
  • Bought Automation for Jira to allow project admins to do more things without needing Jira admin.  We are encouraging this instead of workflow post functions or Groovy scripts.

What great ideas do you have?


Guilhem Dupuy
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 17, 2021

Hi @John Price ,

That is a very interesting question you are asking, I'm looking forward to reading what other Admins have to say about it.

I think what you've done is already great, especially the idea of giving more power to the project Admins using the automation rules.

I have a few ideas but I guess you've already thought about it :

  • Reduce the number of Jira Admins to the strict minimum
  • Make sure the Jira Admins know what they are doing, through a solid Jira Admin training course. I would recommend a 2 days course which is what we are used to doing.
  • Have you already restricted the Team-Managed project creation to the Jira Admins only ? I found this type of project to complicate significantly the Jira administration, by multiplying the number of statuses existing in your Jira instance for example.

Looking forward to reading other ideas,


Like John Price likes this

We have a Jira Admin structure to support 5,500+ users, 1,100+ Company-Managed Software projects, 6 Team-Managed Software (Next-Gen) projects in a single Cloud instance and are approaching 1,000,000 issues:

  • 2 full-time Jira Admins (Subject Matter Experts)
  • 1 Jira Admin does part-time support (SME)
  • 2 Jira Admins who only create Jira projects and update field contexts
  • 4 qualified as-needed Jira Admins who get temporary privileges for tailoring a specific business unit configuration

We no longer allow new Team-Managed Software (Next-Gen) projects.  

We hold monthly Jira Admin CoP with anyone who is a permanent Jira Admin or is eligible to become a temporary Jira Admin.  The topics covered are:

  • Atlassian Cloud Support tickets
  • Configuration changes and clean up activities (all changes require an issue in a Jira Support project and use a specific component to display completed config changes on a Confluence page)
  • Review the change in Jira Cloud stats (snapshot of stats are taken on 1st and 15th of the month. Stats are ones outlined in "Jira Strategy Admin Workbook" by @Rachel Wright 

Our strategy included established tailoring guidelines. Any change must maintain a stable, performant Jira Cloud.  In addition, tailoring needs to support our internal/external regulations associated with development processes, to support the common Jira metrics, and to identify a value add (i.e. increased efficiency).  An efficiency gain needs to balance the long term maintenance required on any tailored/additional configuration element.

Any temporary Jira Admin has to review planned change(s), approach to change(s), and timing of change(s) with one of the SMEs.  Risks and consult points with SME are established.  Required training prior to granting temporary Jira Admin privileges is based on the proposed change and the individual's competency.  We do take advantage of our Premium Sandbox with the temporary Jira Admin privileges.

Like # people like this


Log in or Sign up to comment