Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Enterprise Connection: Custom Fields Edited

Clark Everson Community Leader Apr 15, 2021

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!

12 comments

Darryl Lee Community Leader Apr 15, 2021

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.

Like # people like this
Dave Liao Community Leader Apr 15, 2021

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. 😉

Like Darryl Lee likes this
Darryl Lee Community Leader Apr 15, 2021

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 Community Leader Apr 21, 2021

@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 Community Leader Apr 15, 2021

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. :) 

Like # people like this

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.bi screen.png
  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!).
Like # people like this
Darryl Lee Community Leader Apr 27, 2021

@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?

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 Community Leader Apr 28, 2021

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

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. 

Like # people like this
Clark Everson Community Leader Apr 20, 2021

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

Like Darryl Lee likes this
Dave Atlassian Team Apr 19, 2021

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

Like Dave Liao likes this
Dave Liao Community Leader Apr 19, 2021

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... 

Like Dave likes this
Clark Everson Community Leader Apr 20, 2021

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.

Like # people like this
Dave Liao Community Leader Apr 20, 2021

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

Like Dave likes this
Dave Atlassian Team Apr 20, 2021

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

Dave Liao Community Leader Apr 20, 2021

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). 😉

Like # people like this

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!

Like # people like this
Clark Everson Community Leader Apr 22, 2021

@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

Like # people like this
Daniel Ebers Community Leader Apr 25, 2021

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.

Like # people like this

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.

Like Dave Liao likes this
Clark Everson Community Leader Apr 27, 2021

@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

Like Rob Horan likes this

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

Like Dave Liao likes this
John Funk Community Leader May 05, 2021

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. 

Like Dave Liao likes this

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.

Like Oleh Vasyliv _Reliex_ likes this

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.

Like # people like this
G subramanyam Community Leader May 09, 2021

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 Community Leader May 10, 2021

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

Like Dave Liao likes this

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you