What's the best way to manage permissions between Dev and Prod JIRA environments?

We're trying to figure out governance guidelines for my client in JIRA. They've purchased the tool and a bunch of licenses, but are currently light on support funding. In the future, we might have a dedicated JIRA admin who also manages the governance, but right now we're looking for a solution that assumes less-experienced admin support. The original support model assumed a small support team with Global Admin rights, but they're realizing that the features and customizations that our users want are much greater than they anticipated. However, there's still some resistance to giving Global Admin rights to all our PMs. 

My idea is to implement a three-environment model (DEV, TEST, PROD), where we give Global Admin rights to our PMs in the DEV environment, but only Project Admin rights in TEST and PROD. This way, they'll be able to play around in DEV and create any new Issues/Workflows/etc. they want, and then request that their creation be migrated into TEST and PROD by the JIRA Admins (who will have Global Admin rights in all three environments). We'll be able to have our PMs learn the tool and do most of the actual work in creating what they want in the tool, which takes a lot of work out of the hands of the JIRA Admins. I'm trying to figure out if this three-environment model will work, and if we can split up the permissions this way or if it'll run into trouble. 

This question sounds similar to mine, though it is four years old:


2 answers

Hi Tom,

Recently we published a blog post describing a way to solve this problem that is very similar to your idea and also makes the migration of changes between systems automatic - http://www.botronsoft.com/2016/03/29/how-to-deal-with-the-jira-administrator-bottleneck/

Feedback is welcome smile


1 votes
Joe Pitt Community Champion May 20, 2016

If you are going to use the same screens, workflows, custom field, etc. between projects (one of JIRA's big advantages) you can expect problems with people stepping on each other and creating duplicate fields. One of the Admin's jobs should be reviewing requests and making sure duplicate fields aren't created and any change in workflows is OK with everyone using it. Moving components between JIRA instances can be difficult. As such I don't recommend the process you're proposing.Instead, if they want to experiment download one of the $10 limited user license copies to their machine for them to play with. If they design something they like it can be documented and rebuilt in the real system.

Moving components: https://answers.atlassian.com/questions/234266

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

381 views 1 13
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot