Enterprise Connection: Custom Fields

Clark Everson

Jira issues all use custom fields in some way. Almost all fields are custom, whether it be from apps like Advanced Roadmaps (now included in Data Center and with Jira Cloud Premium) or from Admins creating the fields. The fields come in all forms too, such as labels, text, numbers, dropdowns, and so many more. Without custom fields, the data input into Jira would be hard for many users to interpret and stay caught up on, however, they also have downsides too, such as performance impacts.

 

With that said, how do other enterprises handle custom fields? Are there any that are restricted due to performance impact, whether that be system-based or from a user standpoint?

 

Are there any everyone really likes and recommends?

 

How about naming conventions and standardizing?

 

Are there any practices that you’ve seen implemented around configurations?

 

Any insights with any aspects of custom fields are more than welcome!

 

If you missed last weeks Enterprise Connection please check out @Dave LIAO discussion about Advanced Roadmaps!

Darryl Lee

Here's a small tip:

A client last year had implemented generic custom fields, like "Single Select 1" or "Radio 2" which can be reused for various projects by creating unique contexts for each one.

This was primarily for Jira Service Management projects, because:

1) You can change the display name for fields in Request Forms. So *customers* will see: "Does this user need a landline phone?"

2) Select/Radio fields can have overly-verbose options. So the options would be:
"Yes Landline Required" or "No Landline Required"

We have to "overload" the options for Select/Radio fields, because without context, the agents wouldn't know what "Radio 2" is about.