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?
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.
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.
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?
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.
Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot