I'm trying to configure Jira custom field contexts and I'm a bit confused about how to properly split them within a single project. What I want to achieve is: * Use the same custom field * Within a single project * But have different options depending on issue types (e.g. Issue Type A and Issue Type B) I created: * Context 1 → Project X + Issue Type A * Context 2 → Project X + Issue Type B However, I'm running into issues: * Once a project is assigned to one context, it does not appear as selectable in another context * The default (global) context seems to block project assignment as well * It’s not clear how to properly “release” the project from the default context Questions: * Is it actually possible to use multiple contexts for the same project by splitting issue types? * What is the correct order of operations to split an existing global/default context into multiple contexts? * How should the default context be configured in this scenario? I feel like I'm misunderstanding how Jira handles context assignment and would appreciate clarification or best practices. Thanks in advance.

Hi @nagata shumpei , Disclaimer upfront: We're an Atlassian Marketplace Partner (VIP.LEAN Solutions GmbH), so I'll mention our own app where it directly solves your scenario. What you're describing is actually the textbook use case we've been covering with our VIP.LEAN Behaviours Builder app. We're publishing a dedicated how-to article on exactly this pattern — same project, same field, different allowed options per work type — on our blog this week. I'll come back and drop the link here once it's live. On the native side, Maria is right: Jira Cloud's field context model doesn't cleanly support "same project, split by work type" the way you'd intuitively expect. Cascading fields or duplicated custom fields are the usual workarounds, but both push complexity onto users and onto your configuration. The no-code route with Behaviours Builder: * Keep one custom field with one context that contains all options for the project. * Define a Behaviour scoped to your project + Issue Type A, with an action that dynamically sets the allowed options to just the subset relevant for A. * Add a second Behaviour for the same project + Issue Type B with its own subset of options. * Done — same field, same project, work-type-specific option lists. No cascading, no duplicate fields, no automation rules, no Groovy or Forge code. Everything is configured centrally and reusable across spaces and work types, so you're not fighting the context UI at all. Here an example where field Impact shows different options depending on contexts: Context 1: Space = Template, Work Type 1 = Workstream , Context 2: Space = Template, Work Type 2 = Task Marketplace (30-day free trial): 👉 VIP.LEAN Behaviours Builder on the Atlassian Marketplace Happy to answer any follow-up questions on the setup. Best regards, Fatma

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to split custom field contexts by issue type within the same project?

nagata shumpei

I'm trying to configure Jira custom field contexts and I'm a bit confused about how to properly split them within a single project.

What I want to achieve is:

Use the same custom field
Within a single project
But have different options depending on issue types (e.g. Issue Type A and Issue Type

I created:

Context 1 → Project X + Issue Type A
Context 2 → Project X + Issue Type B

However, I'm running into issues:

Once a project is assigned to one context, it does not appear as selectable in another context
The default (global) context seems to block project assignment as well
It’s not clear how to properly “release” the project from the default context

Questions:

Is it actually possible to use multiple contexts for the same project by splitting issue types?
What is the correct order of operations to split an existing global/default context into multiple contexts?
How should the default context be configured in this scenario?

I feel like I'm misunderstanding how Jira handles context assignment and would appreciate clarification or best practices.

Thanks in advance.

Accepted answers

marc -Collabello--Phase Locked-

Hi @nagata shumpei ,

I assume this is a Jira question. However it was tagged with Confluence cloud, so you might need to change the tags to get some attention.

Maria Rusnakova

Hi @nagata shumpei

You cannot create multiple contexts for one Jira space, even if you specify a work type in the first context and want to assign the second context to a different work type.

If it's a select list and it's okay for you to create it as a cascading field, you could add the name of the work type to the parent field and options to its child.

Another option that came to my mind is to create another field with similar name or special character (f. e. '.' at the end of the name).

Best regards,

Maria

Fatma from VIP_LEAN Solutions

Hi @nagata shumpei ,

Disclaimer upfront: We're an Atlassian Marketplace Partner (VIP.LEAN Solutions GmbH), so I'll mention our own app where it directly solves your scenario.

What you're describing is actually the textbook use case we've been covering with our VIP.LEAN Behaviours Builder app. We're publishing a dedicated how-to article on exactly this pattern — same project, same field, different allowed options per work type — on our blog this week. I'll come back and drop the link here once it's live.

On the native side, Maria is right: Jira Cloud's field context model doesn't cleanly support "same project, split by work type" the way you'd intuitively expect. Cascading fields or duplicated custom fields are the usual workarounds, but both push complexity onto users and onto your configuration.

The no-code route with Behaviours Builder:

Keep one custom field with one context that contains all options for the project.
Define a Behaviour scoped to your project + Issue Type A, with an action that dynamically sets the allowed options to just the subset relevant for A.
Add a second Behaviour for the same project + Issue Type B with its own subset of options.
Done — same field, same project, work-type-specific option lists. No cascading, no duplicate fields, no automation rules, no Groovy or Forge code.

Everything is configured centrally and reusable across spaces and work types, so you're not fighting the context UI at all.

Here an example where field Impact shows different options depending on contexts:
Context 1: Space = Template, Work Type 1 = Workstream ,
Context 2: Space = Template, Work Type 2 = Task
2026-04-20, 12_41_54 p.m.-Behavior_of_Field_Impact.gif

Marketplace (30-day free trial): 👉 VIP.LEAN Behaviours Builder on the Atlassian Marketplace

Happy to answer any follow-up questions on the setup.

Best regards,
Fatma

Trudy P Claspill

Hello @nagata shumpei

In addition to the suggestion from @Maria Rusnakova if you have access to the Assets product (available with Jira Service Management) you can recreate your field as an Asset Object instead and use a custom Asset Object field in your issues. When you configure a custom Asset Object field you provide it with a filter to specify what values to show and you can include the Type of the current issue as part of that filter.

All comments

marc -Collabello--Phase Locked-

Hi @nagata shumpei ,

I assume this is a Jira question. However it was tagged with Confluence cloud, so you might need to change the tags to get some attention.

Maria Rusnakova

Hi @nagata shumpei

You cannot create multiple contexts for one Jira space, even if you specify a work type in the first context and want to assign the second context to a different work type.

If it's a select list and it's okay for you to create it as a cascading field, you could add the name of the work type to the parent field and options to its child.

Another option that came to my mind is to create another field with similar name or special character (f. e. '.' at the end of the name).

Best regards,

Maria

Fatma from VIP_LEAN Solutions

Hi @nagata shumpei ,

Disclaimer upfront: We're an Atlassian Marketplace Partner (VIP.LEAN Solutions GmbH), so I'll mention our own app where it directly solves your scenario.

The no-code route with Behaviours Builder:

Keep one custom field with one context that contains all options for the project.
Define a Behaviour scoped to your project + Issue Type A, with an action that dynamically sets the allowed options to just the subset relevant for A.
Add a second Behaviour for the same project + Issue Type B with its own subset of options.
Done — same field, same project, work-type-specific option lists. No cascading, no duplicate fields, no automation rules, no Groovy or Forge code.

Everything is configured centrally and reusable across spaces and work types, so you're not fighting the context UI at all.

Marketplace (30-day free trial): 👉 VIP.LEAN Behaviours Builder on the Atlassian Marketplace

Happy to answer any follow-up questions on the setup.

Best regards,
Fatma

Trudy P Claspill

Hello @nagata shumpei

sai chinamuthevi

But we used to do this before right? I mean, different contexts for different issuetypes with in same project?

Trudy P Claspill

@sai chinamuthevi

No, that functionality has not been available in Jira Cloud.

sai chinamuthevi

Not in Jira cloud, but In DC i remember i did this. may be i'm wrong but this option is used to be there previously using Contexts

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud