Separate Jira settings for different projects

[Jacqueline]

My company has multiple Jira admins that each are responsible for one or a few projects. I want to know if there is a way to better separate the workflows, statuses, issue types, fields, etc. for each project. We keep stepping on each other's toes and messing with each other's settings, because we all can see and modify ALL of the workflows, ALL of the statuses, etc. 

Note that I am not talking about Project specific settings, like the project name and key, or the project automation rules. I am talking about the "global" settings that are not project specific.

Am I missing an obvious setting or process for separating these? Or is the only solution for my company to purchase and manage two separate Jira instances?

[Mike Rathwell · Accepted solution]

Hi @Jackie Scanlon 

There isn't an easy answer for your ask. There may be some plugins that do that but the way we ended up going was basically kicking all the excess admins out and having just an actual team that is responsible for that that coordinates all the things.

Conversely, you might make another Jira project to manage this stuff and do an actual CCB on changes. 

[Jacqueline]

Thanks. Yeah, sounds like we will need to just coordinate changes better/have better training on this stuff.

[Isaac Trumbo]

You will want to do some work after creating projects to separate Permission Schemes, Workflow Schemes, Field Configuration Schemes, Screen Schemes etc.

If you go to Project > Project Settings > Summary, you will see all the settings and if they are shared or not.

Then as a Jira Admin you go to Settings > Issues > and here go to all the different schemes and settings, copy the default/shared ones into a new one, then change the projects to use the new, individual schemes, with separate workflows, screens, etc.

This way each project admin can update their own settings without affection others.

There a few things such as Statuses and Resolutions that will always be shared across your Jira instances, so it's important to not do things such as renaming statuses, only creating new ones to add to your project workflow

Hope that helped a little.

[Jacqueline]

Thanks, yeah if someone takes the time to check what is shared between projects it works out okay, because they know they'll need to copy that Workflow/Field/Permission scheme and edit the copy instead of the original to avoid messing up someone else's project. I was just hoping there was a software solution to prevent the changes regardless.

[Jack Daniel Morilla]

@Isaac Trumbo - I'm using the same approach as you are, simply cloning the original then updating it to the customized workflows, screens, etc.

[Karen Rogalski]

Your instance is sufferings from too many cooks in the kitchen but here are some ideas:

1) Setup a Project for all Jira user requests and scheme changes. All Jira Admins log their changes there. 

2) Setup a regular Governance/Oversight meeting to review any changes that might negatively impact all projects. Be mindful that not all requests have to be implemented if they affect the long term tool health and maintainability. Learn to say no but document your reason.

3) Purchase Rachael Wrights book. https://www.jirastrategy.com/

4) Accept that there is no right or wrong way in Jira. But the wrong Strategy is certainly not coordinate and work together.

[Joseph Chung Yin]

@Jackie Scanlon -

Welcome to the community.  Generally speaking if everyone can share common standards, then it would be preferred because changes can implemented across the board.

In your case, I would recommend that you setup different objects/schemes (i.e. WFs, Fields, Screens etc...) among your different Jira Admins.  Please note that certain objects (i.e. WF status) are always be shared regardless the projects.

It is important that your admins are not working in silos, they must work together and coordinate with each other of changes that take place in your Jira/JSM environments. Your issues can be handled via team coordination/change management or you have to restrict who can be given the Jira admins rights.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Jacqueline]

Agreed, its useful to collaborate, but its been frustrating to accidentally mess other teams up because one person made a change that they didn't know would affect everyone. The incident that most recently occurred was someone changed the name of the status, creating a domino effect against every other project. It led to a lot of confusion.

Based on your answer, it doesn't sound like there is a way to separate these via software.

[Joseph Chung Yin]

@Jackie Scanlon -

As others have mentioned, your Jira Admins (may be too many) and failed to properly assessing the possible impacts to others prior to their execution.  You should setup a CCB among your admins to go through any change, so everyone agrees and understand the impact of changes.

If my suggestion helps, please click on "Accept answer" button when you have a chance.

Governance is critical within a Jira/JSM env among Jira Admins.

Best, Joseph

[Athas Mark]

We use a naming convention prefix,  by high-level organization to categorize schemas.   GIT: for Global IT admin, R2: for Region 2 admin, ENG: for engineering admin.  Within those groups, the local admin can create what they want, while agreeing not to mess with other groups.  We also have an admin council (CCB) to discuss considerations that impact all of us--e.g., the naming conventions, status group standards...)

[Sarah Elmer]

You could always make copies of the pertinent items, especially workflows for each Admin (i.e. *****-Admin1; *****-Admin 2, etc.). This way when changes are made, they will only work on their own item. We do this for workflows, but it would work with any of the individual items like field configuration, permissions, screens, ...

[Amir Katz (Outseer)]

Schemes is the way to go.

But to manage those, you do need to use a CCB, or a dedicated project for Jira admins to ask for changes.

[Deleted user]

I wouldn't overthink this one.

Once the bulk of our Jira Instance was set up and mature, I did two things that really help me keep my instance organised and stable.

1. Naming conventions; Common workflows, screens, schemes, etc. that apply to a project or the same project category (or in your case, under a certain admin) are all given the same number prefix.

2. Change management using components. I use a Software Project for internal Jira CM, and use the components function to track Jira objects such as workflows and screens as CIs.
Releases show me what changed when, and what component is affected. So when I get a user notifying me of a broken automation, for example, I can see pretty quickly what it would have been that broke it (say, adding a transition or new status to X workflow), or introducing a new subtask issue type)

[caglad]

Just to make it easier - for each project, set up a workflow scheme and let them have their own workflow for their own project. You could do the same with statuses etc

[Joseph Chung Yin]

@caglad -

Statuses are shared objects at the system level.  The best practice is to reduce the number of statuses within an env.  

Best, Joseph

[caglad]

agreed but you could still set up your own statuses (I personally wouldnt)

[Joseph Chung Yin]

You are absolutely right.  However, statuses ideally need to be standardized/controlled, so they are used constantly across the board.  The worse situation is having too many statuses carrying the similar meaning within the same env.

Best, Joseph

[Mike Rathwell]

OR having two "Canceled" statuses with one spelt "Cancelled"

Apparently both are correct but... sigh

My backlog cleanup list from the dark days of when a C level proclaimed Jira is easy so give all managers and above admin is.... long.

I only put up with that for a few weeks before I kicked 'em all back out and the troubles that started this conversation are quaintly simple compared to some of the festivities I had and have to unravel.

Do not get me started on how cockeyed permissions can get.