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

Can a custom field select list have different options based on the issue type/screen it is used for?

I have a custom field called "System" which lists all systems that may be impacted/relevant. Different issue types have different relevant systems (e.g. a "support issue" could be about basically any system, but a "data pull" would only come from one of a select few systems).

can i limit/alter the system options avialable based on the issue type or screen that the custom field exists on? this question sounds like it might be related to what i'm asking for (rerfers to custom field contexts, but i'm not sure if you can have multiple contexts based on issue type for the same project)

7 answers

1 accepted

3 votes
Answer accepted

You can have different options for a custom field based on project or issue type. Not based on screens. Create different contexts for different options as described here:

Yes, that's right. It won't work if you try to do it per issuetype per project. Did you instead try per issuetype and for all projects (global)? Does it work for you?

Based on what I see when I try to configure contexts, it appears that I can only have 1 context for a custom field per project. Is that correct? I modified the default context for my "system" custom field, and applied it to issue type "Support Issue" and project "Support Issues". When I add a new context, I can choose issue type "Data Extract" but I can't choose project "Support Issues". That option isn't even in the list.

That doesn't really work either. The second context forces me to choose a project. Therefore, if I have 3 issue types for the same project (which I do) and I need different values available for each issue type, I can't seem to configure this. Context 1 is global for issue type 1, context 2 is project specific for issue type 2, and I can't tie context 3 to the specific project, or make it global.

I see. Sorry that didn't help. I am not sure why it doesn't work though. Maybe for Atlassian to look at it!

No worries. thanks for the suggestion. I've asked Atlassian to weigh in.

Yeah, it's starting to look like that's my only option. I was hoping to avoid that, simply to make configuration less of a headache, but if that's what I have to do, so be it.

Cool. The only otehr option I can think of is to use same name for different fields. Barring the confusion for admins, that will work fine for users. Another option is Javascript hacks.

Has anybody came up with any solution? I have the same problem (in my case there are 4 issue types).

I have the same issue as described above, I need to be able to have a configuration for 3 issue types in the same project. I would prefer not to have to use the different fields as the value should be searchable across the 3 issue types.

Can you please provide more information about a Javascript solution, I would think the project should not be removed from the list if the issue type is different.

I have the same issues here. Anybody has solutions for this?

Wondering if using "select list (Cascading)" custom field  would allow you to select first he issue type (Service or Data) and based on that, a second list is displayed with specific options for each.

Nic Brough Community Leader May 17, 2018

That won't solve anything.  It will provide a cascading select that offers Service or Data (and then the same sub-lists) on all issue types.

Jobin's solutions are still the only useful ones.

Another way to have a field default to a specific value is within the workflow. Go to the transition and add a Post Function > Update Issue Custom Field (and type in your default value). This method will be issue type agnostic and can be shared across multiple projects, so long as they share the same workflow. Enjoy!

There is a remarkably detailed description of what custom field contexts can be used for, including issue types, at

I know this is an older conversation, but figured I'd add this in case anyone is searching for the same item (like myself):

Any solution to it? Even after couple of JIRA releases we face the same problem.

I'm using the Behaviours functionality of the Script Runner plugin for this (paid plugin).  Not ideal as this should be a built-in function, but it works for us since we needed the plugin for other tasks anyway.

How you achieved multiple context per project using script runner plugin. Can you share your thoughts.

Can anyone update me on how they have managed to achieve this multiple contexts per project?  I have several issue types within a project that all need to display different options in the one Custom Field.  I would love to know how anyone has achieved this?


Nic Brough Community Leader May 08, 2018

Log in as an admin, go to the list of custom fields and find your field, then click configure.  You'll be able to add many contexts, one for each issue type.

There is a problem with it, which is what this question is about - you can only do one set of contexts, based on issue or project

Thanks Nic, yes that is indeed the question. So is there a way to work around that problem of only being allowed to do one set of contexts per Project?  I have 5 issue types within one project and all need to display different values in the Custom Field multi select list, depending on the issue type selected.

If you have ScriptRunner, you can do it through the behaviour functionality.  Below is the script you would need.

import com.atlassian.jira.component.ComponentAccessor

def customFieldManager = ComponentAccessor.getCustomFieldManager()
def optionsManager = ComponentAccessor.getOptionsManager()

def formField = getFieldByName("FIELD_NAME") // update FIELD_NAME with your custom field name
def customField = customFieldManager.getCustomFieldObject(formField.getFieldId())
def config = customField.getRelevantConfig(getIssueContext())
def options = optionsManager.getOptions(config)

// update below OPTION_ONE, OPTION_TWO, OPTION_THREE with desired options
// note the options listed need to first be configured within the full project field context and must match exactly

def optionsMap = options.findAll {
}.collectEntries {
(it.optionId.toString()) : it.value


Thanks so much Carol, I'm looking forward to testing this out when I get a spare few minutes today.  Stay tuned! :)

mm, not sure what's going wrong here for me, I think I have missed a step somewhere.  

The field was created and it has a Global context which includes all the issue types within the relevant Project, and lists all of the 28 Options that I want to be possible at various times.

Then in admin

- I created a new Behaviour

- I entered the script in the 'Initialiser Function' Validation Script section, as per screenshot, with the name of the custom field and the three desired options entered in.

 JIRA Behaviours screenshot.PNG

- Then I used the 'Add Mapping' button to select the specific issue type that I wanted this particular behaviour to apply to.  i.e. the issue type that I want those set of three Options to be displayed on.  
? Was this the right next step?

- Then after adding the mapping, I tried to create a new Issue of that Issue Type, yet all of the different Options for that custom field still appeared on the screen, no matter which issue type I selected the Options for that custom field didn't change.


Not sure what I have missed?

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

[Survey] Development tools and DevOps - share your thoughts!

Hey Community! I work at Atlassian in product marketing and we are conducting a survey to better understand how people feel about their development tool chain and DevOps. We would love if you could...

127 views 1 2
Read article

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