Custom fields hell - how to fight it

[#1]

Developers tend to create as many custom fields as possible in each project they create. Sooner or later Jira Admin will find himself in situation where there are hundreds of custom fields and Jira GUI starts being slow for issue views. Moreover filtering issues becomes harder because there could be dozens of columns for each issue.

How to fight it?

1. Plan it

Whenever developer asks you to create a custom field ask him if he is going to use info in this field for searching. If not or rarely - a good idea would be to add value in question to Description and search using text search. Perhaps using another universal text field holding several values is a good idea.

Also try to utilize "locked' fields. E.g. Start Date and End Date already exist in Jira, all you need to do is enable them on screens.

Finally if developer still needs a new field, try to find something appropriate in existing custom fields and create context for his project/issue type.

2. Limit it

• Omit creating fields with same name - there could be many problems. I'm not telling you that they are hard to solve, but JQL can become counterintuitive. Be creative. Use Start of Development if Start Date is taken.
• Use contexts. Each custom field should be limited to project and issue type.  Don't make global fields.
• Use field configurations. Turn off all fields that you do not need for this specific project

I have a special empty fields configuration where all fields are hidden. Whenever new field is added to Jira I edit this configuration and turn it off. When a new project is created I copy empty config and enable only those fields I need in the copy.

3. Help yourself

It may become cumbersome when you do not add fields very often to recall all proper steps. Thankfully we have a very useful helper - Where is my field. Create an issue in a project, go to View and use ... to start the helper - it will show you what to do.

4. Me bad I use fields with same name

Sometimes you will need "raw" custom field name. Go to custom field, select ... and look at browser status line - internal ID of the field is the last digit, something like 13400.

That's all folks, add your comments if you will.

[Velizar Borisov]

If anyone is preparing a "Jira Bible" , that article should be in it!

Thank you Sergei!

[Nic Brough -Adaptavist-]

I think this point is not explained too well:

• Use contexts. Each custom field should be limited to project and issue type.  Don't make global fields.

One of the reasons people end up with "fielditis" is because they do this.

I was hired <mumble> years ago because a large Jira had been doing this sort of thing and had got into a total mess.  3,000 fields is not managable and makes a complete nonsense of any chance of reporting.

The fix - use global fields as much as possible. When the fields are for the same thing.

The most explainable and simple example was that projects had set up over forty pairs of start and end dates.  Can you imaging the JQL you'd have to try to write to answer the question "show me un-started issues past their start date"?  And using the issue navigator with 80+ date columns for the results?  You can't actually do it because you run out of space to write the query!

The fix here was to take it down to one pair of generically named start and end dates.

I would say your rule here is absolutely right for fields that other projects won't be using, but wrong for fields that people should widely have in column.

[Sergei Gridnevskii]

Hi Nic, I think you are right if your company uses Jira for one purpose, e.g. development.

Ours uses Jira Software and Jira Service Desk. Most service desk projects do not need developers fields. 

Other than that we have 10% of business projects that are usually shown to investors and stakeholders to show progress of tasks and plan strategy. They do not need developers fields.

Adding new project to existing context is a matter of two clicks of a mouse.  Or even better - new context allows to have e.g. alternative options for selection omitting the need of creating a new field.

So verdict - if you have similar projects and homogeneous Jira structure - use global fields and do not have complexity of configuration. If your Jira is used by support, business, developers and security guys - use contexts. 

[Bill Sheboy]

Yes, and...I also suggest...

• Jira Admins have a DBA (not a DBE) background (i.e. experience / training / skill) in order to have productive conversations with people requesting custom fields.  That could head off nightmares of storing dozens of critical data attributes in description fields, and trying to figure out how to parse them with the limited capabilities of JQL.
• Our vendor anticipate and resolve/mitigate the potential Jira instance impacts (maintenance, performance, confusion, etc.) introduced with team-managed projects ability to create custom fields at project scopes