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!


Too many Screens Schemes

Hello Community,

I have inherited a Jira Server instance to which I do the admin. It’s a mess . . . just to be blunt and to the point.

I had a request to import a CSV file but the fields were not there. Fine! I went to the Screen Scheme under the Issue navigation and horror . . . 600 plus Screen Scheme Names. I have never seen such a mess!

I later discovered that a new created Jira Project doesn't create its own Screen Name. Wonderful! Chaos on top of Mess

So, I did find the “Default Field Configuration” to which I have added the required fields. I did not find a scheme with the Project’s name nor its Key. Nevertheless to say, the fields are still missing in the import. I did also try the External System Import without success.

In short my questions are:

  • How to solve this import issue?
  • How to clean all the Schemes and got only the ones I need?
  • How to export the list of projects using a specific Scheme?
  • Pitfalls in consolidating such mess?

I will also fill this either as BUG or UNWANTED FEATURE because Jira how it works it is a real mess and makes the Admin impossible.


Any input? Please?



Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Jul 15, 2019

The complexity that Jira lets you create is a function of its power.  If you want to reduce the complexity of the system, you pay the price of loss of flexibility.

Your story is a familiar one to experienced Jira admins - we've all inherited systems that are a mess like this.  It's because too many people were given access and/or a lack of governance.  Admins have have said "it's flexible and allows me to be different to my colleauges so I'll just change it without worrying about everyone else"


  • How to solve this import issue?

Temporarily, make it worse.  Create schemes that include all the fields you want to import, and others you want, apply it to the project that wants the import, then import the data.

  • How to clean all the Schemes and got only the ones I need?

Use the "delete" option in the inactive schemes to start shortening the schemes, then find schemes that are used a lot (again, you might want to use new ones), and get your project owners together to discuss which smaller set of schemes you want to standardise on.  Move all the projects to those, and then delete anything listed without a project.

  • How to export the list of projects using a specific Scheme?

There's no export, but the list of each type of scheme shows all the projects using it.

  • Pitfalls in consolidating such mess?

Users being told they have to work in similar ways can encounter resistance, but pointing out that your reporting and processes are probably totally incoherent can help

  • I will also fill this either as BUG or UNWANTED FEATURE

Don't bother, it is this way by design, it's not going to change.  "Hey, can you please reduce the power and flexibility of your product making it less useful to most of the users" is not something most product owners will buy into.

Like coiram likes this

Hi Nic,

Thank you for your reply.

I start from my last question and your reply.

I've been working in Software Configuration & Change Management field for 18 years and to date, Jira is one of the most cumbersome tool I've used. It is good, but it has no Governance. Also "it is by design" doesn't mean it should be considered a feature but rather it is bad design.

Governace has its meaning and it is considered to bring order to chaos. If a tool doesn't do that not it is its purpose, let's go back to pen and paper the result will be the same . . . and it would cost less, much less.

It is also true that testing a software application costs money, hence it is left to the end-user to report problems. But also selling what the consumer wants doesn't mean that is a "good" product . . . plain and straight opinion.

So if the last sentence it is true, on BUGS:

If power and flexibility of a product means more than 300 projects got changed in a split second because of ripple effect of a user changing a workflow, I would consider it a very bad design, actually a BIG BUG!

-  If power and flexibility of a product means no Governance but just a tool where randomly record "stuff" I stand by my idea of "use pen and paper".

Polemics aside, at present I have this monster that I have to domesticate. I wanted to get an input from anyone and my initial toughts and approach were right.

I see myself working of afternoons and evenings addressing this issue . . . if I will ever been able to fix it or I want it to.

Thank you again for your input Nic.


Log in or Sign up to comment