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

[Tom Abella]

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:

https://answers.atlassian.com/questions/24527

[George Dinkov _Botron_]

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 

Thanks!

[Joe Pitt]

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