Service Desk uses custom field way much better - update JIRA Screen customization as well!

Applied for a trial version of ServiceDesk and I was impressed by its ability to use custom fields but with different display names!

This is an absolute must have for JIRA Core as well! Any plans to implement this soon?

Reason? Our instance (cluster) is HUGE and having 50 custom fields when 1 UserPicker custom field is actually just needed (e.g. Approver, Manager, Partner, Key Person, Lead Developer, etc...) will significantly help performance.

We currently have over a thousand and the reason it's stopped growing for the past year is we have to say NO to our users which totally sucks for them.


We have a brilliant team who made a self-service way to create Confluence Forms which does the same thing, but not all teams want to use thing (and with good reason!). JIRA really needs this ability.



1 answer

0 votes

I don't think you'll ever see that happen. 

The reason you've got loads of different fields with different names is that they are for different things.  Lumping Manager, Partner, Lead developer and so-on into one field is nonsense, as you then have no way to search for the different roles in the field.  How do I search by "lead developer = nic", when I'm lead on issue X and partner on issue Y - any search is going to pull back both records because they're now the same field.

Your problem is structure and/or procedure in your organisation, and the software can't help you with that.


That is simply remedied by having a mapping.

project X has UserPicker1 = Lead Developer

project Y has UserPicker1 = Partner

Each project is independent so there's no harm for us. Your concern is very much real of course in some cases.

But look at the benefits. I guess it depends on where we are coming from and priorities. Having a growing group company with currently ~50k users and ~3k projects will only mean more custom fields. Of course structure and procedure can help but that's such a huge scale/endeavor to do.

I think you've misunderstood the problem.

When I search for "UserPicker1 = Nic", I'm going to get all the data where I'm Lead Developer or Partner.  There is no way to search for "Partner = Nic".  Your design does not work.

Nic, you are misunderstanding it still.

Let's say:

  • Project X will require 3 UserPickers because you have Lead Developer, Partner and Approver fields.
  • Project Y requires 2 UserPickers because it needs Supervisor and Tester fields.

In normal scenarios, 5 UserPickers custom fields are created.

In my proposal, only 3 UserPickers would need to be created because you just re-use it and map it accordingly.

I believe in your train of thought UserPicker1 was used as Lead developer AND Partner for Project X.


I hope you get my point now.


It does not work.

Using your example, you create the three fields for X and then reuse two of them for Y with different "mapped" names.

I want to search for issues where I'm the Supervisor.  A search on Supervisor is going to return issues where I'm also a Partner.  Because they're the same field.  The only way to make it work is to define them as different fields, which is what JIRA already does.

Now, for some other types of field (select lists), you can define a context which gives you the option of different lists of options for each context.  Which solves that problem (but it's not implemented well in JIRA because you can't really do it for several projects and issue types)

Hi Nic,

Like I said, projects are independent.

But then again, wouldn't this JQL work?

(project = Y and UserPicker1 = name) and (project = X and UserPicker1 = name)


It will work, but it requires the user to completely understand the mapping, and it's useless for cross-project reporting, because there's only one user field there, so you can't logically split the data.


Thanks for your input Nic.



Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,427 views 15 19
Read article

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you