Are there limitations to number of options in custom fields?

[Daniel Bower]

Are their limitations to the number of options one can have in custom fields?  Hard limits or performance limits?  Are their ways to improve performance when using a custom field with a large number of options?

My situation:
I have a custom field that is a multi-select with our customer names.  The list of customers is quickly approaching 10,000 (good for the business, not good for a JIRA admin).  The page is obviously very long with that number of options.  When I need to add/remove individual customers, the Edit Options screen takes a while to load. To click any link on the page I have to mouse-over it for about 6 seconds before I can click the link/button/etc. 

Is there a better practice for a field with this many options?  There's no scripting or anything complicated about the field, it's just a list of values.  But it's a very long list and a growing list. 

If it would help, I could get more hardware thrown at the server, but I'd need to know if that would directly impact performance in this particular situation.  Besides this field, we have no issues with performance.

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

There is no hard limit but I strongly discourage this approach because of useability concerns. A list with 10K issues are not going to help the users or admins. I am surprised the users haven't complained yet!

As you already experienced, performance on page load will also take a hit because of those many options.

If you can limit the options based on project and/or issuetype, that is the best option. If not, go for a component or user picker style field where the options appear as the user types in the letters. You will have to develop the new field type (or purchase a plugin that has it) and migrate the existing field to the new type. But worth the investment given the pain you will come across later.

[Daniel Bower]

It is a field where users can type in a value and it auto-completes. I agree it wouldn't be useable otherwise. It's used by tech support when a customer-reported issues comes in, so they can type in the customer name. I'm not sure how I would break that up into smaller lists, the best I could do is by industry which would only get us into about 5 smaller lists, but that would leave it on tech support to know which industry-specifc field to use - and we'd have to change queries. When creating an issue, the auto-complete actually isn't too bad a second or two after you begin typing it presents matches. I'm curious if throwing additional processors or memory at the server would help, or if there's limitations in other places like web server, client side, etc. In which case I will just live with it as is. Does data type in the options matter, if I stripped special characters out of the customer names in the list would that have any impact?

[Jobin Kuruvilla [Adaptavist]]

Make me feel a lot better to know that it is an auto complete field ;) I do not think adding too much memory would help because the processing time is probably most spent on the client side. Maybe you can think about caching some of this data on the client side and that will probably improve performance! Don't think special characters will cause any issues unless you are seeing some javascript errors (possibly caused by parsing of results).

[Marcel Wantia]

@Jobin Kuruvilla [Adaptavist] do you know a plugin that brings in a new custom field type cascading select with an ajax autofill style or similar to solve this kind of problem? 

We are facing the same problem with our Jira instances.

[Brad Cobb]

Try this one:  select2

https://marketplace.atlassian.com/apps/1220214/select2?hosting=server&tab=overview

[Vishal Gautam]

We had this requirement where we needed to load more than 15k options and allow it to grow 2 to 3 times. We first tried with a multiselect custom field adding a JS in the description to allow search but it did not work, was taking 2-3 mins just to load the page. We also tried select2 add-on but that also had similar issue as it also requires all options to be loaded on the client side. 

We solved this issue with this approach - Instead of a drop down, we created a project and a new issue type and added all 14k options as new issues in that project. Now we are using a multi issue picker field provided by ScriptRunner add-on and it works like a charm as it has aut-suggest feature and it can scale easily to as many issues as your JIRA project has.

regards,
Vishal

[Yatish Madhav]

Thanks for this post ... Is there any progress or update in terms of how Atlassian is approaching this topic for Cloud instances? I.e. we also have a field or 2 that have +5K options and it is populated via the REST API ... But not sure how to handle the performance degradation on the UI side as a result of the number of fields.

[Greg Brailsford]

I created a project where each ticket is a customer(client directory). I then created another project for employees(personal directory). Each time a ticket is emailed in I parse the email address to a custom field then link that new ticket to both the ticket in the client directory and the ticket in the employee directory. If that email address is not in our crm I also parse the domain and try and link the email to at least the company. I then set the assignee of the new ticket to the assignee of the company.

[Andriy Yakovlev [Atlassian]]

Please be aware of https://jira.atlassian.com/browse/JRA-44588 , Multi Select List  and CascadingSelect fields are affected. JIRA needs to cache all values and it's doing in non-optimal way. 

[MattS]

If your problem is just how long it takes to add new options as an admin you could try a REST resource or a custom admin page. I'm impressed JIRA works with this many options. 

[MattS]

Or script runner and a script to add a new option

[Matt Doar]

Buil-in scripts, bulk custom field options works well.