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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Custom fields hell - how to fight it

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 Community Leader Jun 30, 2021

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

Thank you Sergei!

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.

Like # people like this

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. 

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


Log in or Sign up to comment

Atlassian Community Events