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.

[Dave Liao]

Ooh, that's an extreme of creating globally-shared custom fields for use in multiple places. 😅 

When advising teams who are setting display names in JSM projects, I tell them to try to keep the spirit of the original custom field so you don't need a decoder ring to figure out what field is actually filled out when a request is filed. 😉

[Darryl Lee]

That's a good point. I guess I've spent so much time trawling through custom fields trying to see if there's any existing fields with similar meanings/interpretations (thesaurus anyone?) that I liked the simplicity of the generic approach. But sure, "Options" and "Selection" might work too. :-}

[Clark Everson]

@Dave Liao 

I don't know if I mind this approach. You would just need to use different field configurations. Though I think maybe standardize field configurations via department or something so that they mean the same thing for certain working groups

[Mary Ramirez]

There's alot to unpack here!

• I recommend auditing your current instance and measuring it against Atlassian's recommendations https://confluence.atlassian.com/enterprise/jira-data-center-size-profiles-955171062.html 
• With naming conventions, I recommend creating custom fields that can be easily used by multiple teams and leveraging field configurations and context to customize it.
• I prefer multi select vs single select. In my experience, a single select field is created and then a request is placed for something similar but with multiple options. It's easier to just create a multi select field so that it can accommodate both use cases and the fields can be re-used by multiple teams.
• Share screens and screen schemes! If you leverage the context of custom fields then you can also share screens. If the field doesn't have a context, then it won't appear on the screen. If it does have a context, then it will appear on the screen. 

If nothing else - reduce and reuse. :) 

[Sasha Solig]

Hi Clark, this is a great topic!

It's a constant balancing act between re-using a minimal set of generic custom fields and "giving users what they want". Whenever I create a new project I follow this process:

1. For each new custom field, search existing custom fields for something identical or relatively close. If you find something close, try to  persuade the business to use it.
2. If you have to create a new custom field, keep the name short but at the same time try to avoid abbreviations and acronyms that not everyone may understand. Short names avoid clutter on the issue screen and make filters etc easier to configure.
3. If required, a more verbose field explanation can always be added to the custom field description. Make use of HTML embellishments or use the Message Custom Fields to make important information stand out.
4. Try to use consistent field types within a project. I generally prefer select lists to radio buttons and check-boxes (which effectively perform the same function), however sometimes you want to see all the options on screen so radio buttons and check-boxes may be more appropriate.
5. Performance is definitely a concern, especially when dealing with a single, fast-growing on-prem server Jira instance. But at the end of the day, what's the good of a high-performing Jira environment that is confusing to business users? Like I said, it's a balancing act. To that end, use field contexts where appropriate, clean up obsolete custom fields and projects, and re-use existing fields where-ever possible.
6. Although I have limited experience with Service Management, I would try to avoid radical renaming / re-purposing custom fields within request types as suggested above, as agents still access issues via the classic screen / field names so there could be potential confusion. Not sure if next-gen / team managed projects get around this issue, however as these are only cloud-based something I haven't had to worry about (yet!).

[Darryl Lee]

@Sasha Solig - Just for my own reference, Message Custom Fields are part of the Toolkit Plugin for Jira, right? I see this on Cloud, but it looks like it's still only available for Server, not DC? https://marketplace.atlassian.com/apps/5142/toolkit-plugin-for-jira

As for that pop-up with Idea Level definitions, that looks slick, but is it a JavaScript hack, similar to this? https://confluence.atlassian.com/jira064/creating-help-for-a-custom-field-720412166.html

I thought that JS in descriptions were deprecated a while back. Is that using a plugin I'm not aware of?

[Sasha Solig]

Correct and looks like the (free) Toolki Plugin is only available for server. However there is a note about deploying server plugins on DC under the Hosting Options drop-down in the Marketplace page.

The custom "tooltip" is all HTML and CSS.

In the message custom field description goes the HTML (some HTML tags are difficult to get working, presumably due to conflicts with the Jira style libraries):

<div class="help-tip" style="top: 8px; right: 10px;">
<p><b>Level 1 - Just Do It</b> - Ideas that can be implemented in your own team in less than 1 month
<br /><br /><b>Level 2 - Business Improvement</b> - Ideas that require assistance from other departments to implement, and will likely take longer than 1 month
<br /><br /><b>Level 3 - Research & Development</b> - Ideas that require specialist experience and new technology solutions, particularly where the long term benefit is not clear
</p>
</div>

In the Announcement Banner goes the CSS:

<style>
.help-tip{
position: absolute;
text-align: center;
background-color: #BCDBEA;
border-radius: 50%;
width: 24px;
height: 24px;
font-size: 14px;
line-height: 26px;
cursor: default;
}
</style>

Can't remember where I got the original hack from, but it has proved useful in many situations to enhance the blandness of OOB Jira forms. 

[Darryl Lee]

Oh wow - that's nice and easy. It's been a while since I've had to use hacks like that. (I've been in a Cloud world for the past 16 months.)

I vaguely recall remembering how they seemed particularly fragile. But I guess they're "officially supported" (even as it's disabled by default), so all is well:

https://jira.atlassian.com/browse/JRASERVER-70859

[Phill Fox]

Custom Field Contexts! Avoid those circumstances of having fields with the same (or similar) name but with different sets of options. But remember to document what settings are in each context. 

Field Configuration Contexts - only show fields on projects where they make sense. 

Loads of other stuff but these are my top two tips. 

[Clark Everson]

Field contexts save so much time, and combine that with field configurations for different definitions

[Dave]

It's interesting that you specifically mentioned custom fields from Advanced Roadmaps, @Clark Everson. Knowing what custom field types to support has always been a challenge for us - we think that we've got pretty good coverage of custom fields but it would definitely be good to know which custom field types we're lacking support for that people would really like to see added. We actively respond to in-product feedback so I'd encourage any user of Advanced Roadmaps to let us know their needs!

Regards,

Dave

[Dave Liao]

I'll encourage folks to do so! I ran into a user on Community who was asking for version custom fields to be supported, let me find the post... 

[Clark Everson]

Our team is just getting started with Advanced Roadmaps, but as we discover more I am sure we will receive requests. Currently I can't think of any yet but I know this will change.

[Dave Liao]

@Dave - found it! Let me know your thoughts - or the actual poster? 😊 Appreciate any attention your team can offer.

[Dave]

Thanks @Dave Liao - I must have missed that, I'll respond to it today!

[Dave Liao]

Thanks for the mention @Clark Everson !

I have so many thoughts on custom fields - but a lot of the respondents covered the broad strokes (and then some). 😉

[Callum Carlile _Automation Consultants_]

Whenever a new Jira dev joins my team, I always try to set a precedence - the FIRST thing I get them to check when building something new in Jira is whether or not the field/status/any other global artifact exists, OR if a very similar artifact exists which can be re-used.

It sounds slightly obvious, but it's amazing how many Jira admins I have worked with who just create new fields at the drop of a hat, without even doing a quick search of the existing custom fields.

In my experience, many technical issues relating to large amounts of global artifacts which come with scaling Jira can be avoided through proper training and standards across the organisation. Of course, the bigger the company, the more unique fields are going to be required, however regular training from the get-go can be a good way to combat this, and can reduce issues in the future!

[Clark Everson]

@Callum Carlile _Automation Consultants_ 

I would 100% agree. I was lucky enough when I was learning Jira my previous boss told me to do all the training first. So we developed a path and went from there. But the instance I took over for, very few people followed that process and it had created a mess.

Clark

[Daniel Ebers]

This is a topic which is always current with the teams I worked with so far and I feel it needs attention and discusstion , at least every now and then.
Although we have governance processes in place which intend to prevent some basic configuration mistakes there are still instances which inherited a less tidy setup (based on their history, almost always some migration scenario was involved).

We found the topic to be split in many parts therefore:

• is the instance burdened with some historical ballast?
  If so, we mainly follow the guides available like the recent one here
  https://confluence.atlassian.com/clean/cleanup-guide-1018788576.html
  but also utilized the JIRA Strategy Admin Workbook (https://www.jirastrategy.com/)
  
  
• is it a new request?
  Then we let the requestor go through the same processes that were basically here mentioned.
  We ask if there is a similar field that could be suitable or if a generic one does also the job. We also offer migrations from a former data type to a new data type for existing users, in case "an upgrade" from single select to multi select is desired. This is only to prevent having a second field of type "multi" doing the same job.

Some information we always try to give away on top (you will see it is, again, split up in two parts):

• the technical side
  We met highly technical staff which explained how new hardware could "answer all the questions" and while we agree to some extent that there always will be more powerful hardware that could be bought we raise awareness for a different topic.
  
  
• the administrator side / or "the organizational" side
  We ask if the application admins really want to crawl through dozens of similar-named custom fields, basically needing more time to scroll than to work.
  This topic is extremely important to us and we also encourage application admins to document changes.

Also the users must not be forgotten. Who ever wants to see the same custom field name over and over when intending a quick JQL query, guessing what could be meant and what which field is right.

There are always users that claim there is a need for 30 custom field for some very special process - sometimes this is even relatable when going through all the docs and papers.
As there is no intention to refuse them the configuration they need to get their team started and a great product into the market there are some exceptions to the all said above (but rarely) and there is always the option to have a more specialized solution (like a extra Jira Cloud instance) for a short-lived but highly complex project.

That all leads to the scenario however that we have seen Jira instances that are configured more rigid (you won't get a new custom field, don't try to ask) but others that are wrapped in governance processes but a lot more flexible - and a mix and match of scenarios in between.

The main take away for all scenarios I met is: speak to the requestor. Something that seems to me very well working in the Community - asking what is really meant, offer consulting and alternative options.

On a technical side, everything said here is very true and we made positive experiences during the years with:
- assigning contexts to Custom Fields
- re-use them where possible
- consolidate where possible (mostly brings communication efforts with it but it worth the work)
- ask if an alternative approach could be better (in case a whole bunch of Custom Fields is needed sometimes a table could be the better choice)
- use multi selects if nothing is particularly against it
- document everything and use change management procedures (for all Jira application config including custom fields)

The list is by no means complete - there could be a lot more said about it. Also Workflows, all the Schemes and other global configuation need a good considered concept and attention from time to time - if the intention is that users can log in with some "joy" to do their work ;)
From what I experiences outlining those "basics" are more time-consuming than every operation of the system or user support itself - but worth doing it.

[Rob Horan]

Just a dream idea, but I think for Enterprise organizations, field contexts should have an additional, higher level of granularity.  Right now you can allow fields to be used on a project by project basis, but lets say one division of an organization needs a field for all of its projects, but no other divisions need it.  It would be great to not have to manually select each project for that division.  So you allocate the field to that division and still reap the performance benefits, and then if you want to pick and choose from projects within that division for further granularity, so be it.

Also, the ability to explicitly exclude projects would be great.  Sometimes that's an easier approach.

[Clark Everson]

@Rob Horan 

I agree the field context menu in both Cloud and Data Center could use some loving. Not only for the aforementioned reasons you said, but also it's very easy to accidentally unselect everything and can cause much bigger problems in my opinion.

I will see if I can find a feature request for this and share it here!

best,
Clark

[Sasha Solig]

Agreed, I have never liked multi-select list boxes for just that reason (especially when the list extends beyond the visible range).

[John Funk]

It's certainly easy to get lost in a sea of custom fields. Contexts are a must! And it gets really confusing if you add custom fields with the same name in multiple Team-managed projects. 

[Rob Horan]

I disagree on contexts - they wind up being very difficult to keep track of.

Screens and field configurations work very well.

I wish Atlassian disallowed the creation of identically named fields.

[Paloma Fondon Araujo]

I agree with you @John Funk ! We must flee from fields with the same name!

[Oleh Vasyliv _Reliex_]

One of the biggest challenges is the lack of possibility to reuse the same custom fields in multiple Team Managed Projects (legacy Next-Gen).

As a result, this ends up in multiple custom fields created with very similar or even identical names in TMPs (which is an absolute nightmare later on e.g. when you are building a cross projects JQL).

There is a 2-years old ticket about this case and so far no real actions: https://jira.atlassian.com/browse/JSWCLOUD-20905

Hope this post could bring some attention to that issue.

[G subramanyam]

Thank you @Clark Everson for this post. I'm learning new tips from this thread and way of seeing them from different angles. I would request you to post more use cases on custom fields.

[Clark Everson]

Hi @G subramanyam 

The Enterprise Group is currently working on discussions to find out these use cases. The above responses actually cover everything I am able to think of, though if others have ideas I would love to hear them.

Best,

Clark

[Fadoua]

This is a very interesting topic that many admins still disagree about. To make my answer short I am against too many fields. Generic fields can be more than useful. Trying to customize fields for each fields will end up with a messy slow instance. 

For example: why having a field called marketing team? We can have team as a text field and each team can enter their name.

Like I said this is an interesting topic that will be worth an article.

Best,

Fadoua

[Shrikant Wagh]

I noticed that when screens are not well thought, there is explosion of custom fields, and lots of duplication. My suggestion is always plan what your goals are, look at all projects you have and reuse the fields as much as possible.

[Shrikant Wagh]

I am looking for multiple user picker custom field in Jira any suggestions?

[Shrikant Wagh]

Jira do not have custom field to include tables, but I noticed that there are other vendors in marketplace provide tables for Jira. Does anyone has any experience with Jira tables you would like to share?

[Shrikant Wagh]

Looking for something like this.

[Shrikant Wagh]

For server or locally hosted instance you can write your own plugins or modify ones. Is there any such workaround for cloud version?

[Dave Liao]

@Shrikant Wagh - did you ever find an answer to your question?

Are you looking to develop your own custom field in Jira Cloud?

[Alex Koxaras _Relational_]

Interesting question! I liked all answers!

[Hana Kučerová]

When it comes to custom fields, I like Power Admin app by Botron very much. It shows you all the usages - issues, boards, filters, dashboards, screens...

One of my customers needed to separate from the bigger group of companies - they used one big Jira together, so I had to find out, what's relevant to my customer and what's not and they didn't use the contexts at all. Thanks to this app I was able to get rid of more then 300 custom fields of approx 450. 

[Dave Liao]

That's such a wonderful cleanup activity!

[Dave Liao]

Future article idea - how to Marie Kondo un-needed custom fields (and un-needed custom field contexts) in a well-loved Jira.

And how to over-use hyphens.

[Kishan Sharma]

Like everyone suggested, we should have a process to gather requirements from users like  why a new custom field is required, its purpose and whether an existing custom field can be re-used before creating a new one.

[Dave Liao]

@Kishan Sharma - good idea! Have any suggestions on a process you've developed or seen?

At the very least, if someone asks us for a new custom field, we should have a checklist of questions asking the requestor for more details.

A listing of the current custom fields (maybe in Confluence?) would be needed to support such a process.

[Kishan Sharma]

Hi @Dave Liao Thanks, you have already guessed it right, we have a confluence page where we have listed all the fields and their types which users can refer and decide which of them they can re-use. If at all those doesn't fit for their requirement, then we go over a call to discuss it in detail and finalize whether we should go ahead with creating them or not.

[Suvradip Paul]

@Clark Everson  - Great Topic! I have mixed experience with customization and I must say I found mostly enterprise organisations are not quite keen for introducing customisation if that's not too urgent and the most simple reasons  are there might be too many requests in future and worrying about the performance impact. On the other hand, yes there are needs of customisation depending on the scenario.

[Dave Liao]

@Suvradip Paul - I feel like when it comes to custom fields, many companies don't realize the full impact of adding tons of custom fields, so teams will request ALL the fields, all the time. 😂

[Suvradip Paul]

@Dave Liao   Spot on mate!

[Fabian Lim]

In our organization we migrated two instances into one and ended up with 3000+ customfields. We try to re-use as many customfields as possible.  

We also use contexts extensively to ensure that performance doesn't get impacted and avoid calculated customfields as much as possible.

[Dave Liao]

How do de-duplicate and consolidate these 3,000+ custom fields? It's quite the challenge, yeah?

I'd hope that with 3,000+, there's no need for more... 😅