Multiple field contexts per space is coming to Jira - join the Early Access Program

August 18, 2026

Hey everyone!

We’re getting ready to introduce support for multiple field contexts per space, and we’re looking for customers to help us test it through an Early Access Program (EAP).

Today, a custom field context can be associated with a set of spaces and work types, but a space can only have a single context for a field. We've heard from you that this can make it harder to model certain field setups and can lead to workarounds requiring heavy overhead.

With multiple contexts per space, Jira will support:

More than one context for a single space across different work types
Different default values for different work types within a single context

What we are looking for

Sandbox sites only
New field schemes must be enabled on the site. Learn more about the new field schemes.

What's included in the EAP

Creating multiple contexts per space in the existing Jira admin experience
Setting different default values per work type via the Jira UI
New REST APIs for reading and setting context default values
Core Jira experiences correctly handling default values and options when multiple contexts exist for the same space

The EAP will include two milestones:

M1 (September 2026): the ability to create multiple contexts per space for a field
M2 (October 2026): the ability to set different default values per work type within a context

Some parts of the EAP are still in development, so the exact feature set and timing may change as we continue testing.

Areas that won’t be available in the EAP include:

Multi-context support for migrating tenants
Jira wide support for handling default values and options when multiple contexts exist for the same space (EAP is scoped to core experiences only)
Fields owned by apps

API changes and deprecation plan

To support multiple default values for different work types, we’re introducing new default values REST APIs. The existing APIs for managing custom field context default values are no longer fit for purpose once multiple defaults can exist for a context.

Learn more: Deprecation: Custom field context default value REST APIs

Change	Target Timing
New default values REST API introduced	September 2026
Existing APIs change behaviour: reading default values from a context with multiple defaults will return an error, and setting default values will populate the default for all work types on the context	September 2026
Existing default values APIs removed	March 2027

If you use the existing default values APIs, please start planning your migration to the new APIs ahead of March 2027.

How to get involved

Register your interest by submitting the form below, we’ll be in touch with selected participants with more details, including eligibility, timing, and how to get your sandbox site enabled.

Thank you for your support and feedback as we continue improving how fields are managed in Jira.

10 comments

Great news @Carol Low !

Gone are the days (or they will be soon) where we need to set up duplicate fields for different values on the same space :)

Can't see anybody not loving this!

Like • like this

Wow! This is a game-changer.

I've had several cases where we had to create multiple work item types purely to work around the single-context limitation. Having multiple field contexts per space should simplify configurations significantly and may also reduce the number of custom fields we need to maintain. Really looking forward to seeing this in practice! ✨

Like • like this

@Carol Low will it be available only for Jira Software or JSM as well?

Will it work on Customer Support view, and is there a plan to support it not only for Work Types but also for Request Types?

Like • like this

Hi there,

signed up with my On-Atlassian instance (hope that works too).

Great to see this coming — multiple contexts per project is one of the recurring pain points we hit in DC-to-Cloud migrations. A few questions from a Marketplace partner perspective (we build Forge-based custom field types and deliver enterprise migrations):

App-owned fields are excluded — is there a roadmap for parity? If native fields gain multi-context and per-work-type defaults while app fields don't, customers will read that as an app limitation rather than a platform one. Even a rough timeline would help us communicate honestly.
Will the new default value APIs support Forge value types (e.g. forge.object) from day one? Apps set context defaults via the current defaultValue endpoints today, and RFC-135 (which introduced the new defaultValues endpoints) didn't mention forge.* value types at all — has this been resolved? If the replacements ship without forge.* support, the six-month migration window (deprecation notice CHANGE-3082) gets tight for vendors.
Multi-context per project is a behavioral breaking change for API consumers: code reading the project-context mapping can currently assume one context per project. Will there be a developer changelog entry flagging this, and a way for apps to detect whether a site has the new field schemes enabled?
Please reconsider excluding migrating tenants — in DC, multiple contexts per field are common, and migrating customers are arguably the primary audience for this feature. If M1 can't include them, a statement on when migrated sites will be supported would help migration planning a lot.
How will per-work-type defaults (M2) interact with app-rendered field configuration screens — will the native UI appear for app fields, be suppressed, or coexist?

Happy to test with our field types and report back.

Like • like this

@Carol Low this is great news!

Can you define 'core experiences' and 'Core Jira experiences' please. Do you mean only Jira (Jira Software?) and not JSM?

You mean to tell me we will be able to have multiple contexts for the SAME field in the SAME Jira space? Maybe, I'm missing it; but it seems confusing. How will the JQL work with this to identify the exact results needed?

I'm still about confused about Field Configs and Field Config Schemes being replaced with Field Schemes (the functionality hasn't hit the instance I support yet).

@Carol Low - Some videos would be great please!

This is awesome! Signed up for that right away.

It'll be nice to have different options available for fields, such as select lists, for different work types in a space. We have so many variations of the field name "Type" because of the lack of this feature.

@Dirk Ronsmans @Brita Moorus @Dusty Brossart - great to hear!

@Lior Pinelis - it would work for JSM but no plan to support Request Types as yet.

@Paul Pasler _Seibert_ - please feel free to direct these questions to the team in your request ticket, some of these are better answered by the eng team. Exclusions from the EAP is not a signal that it won't be included in GA, we just wanted to get started testing things that are ready, and will include the features into early access as they become available.

@Julia Foden - there are some views in Jira that are less commonly used that include jira widgets in confluence, calendar view etc that won't be included for EAP but we will continue to work on supporting all views. This might include some views in JSM as well, but core experiences like the work item view, boards, JQL, etc are expected to be fully supported.

@Apryl Harris - This just means a field can have different dropdown options on different work types, e.g. A,B,C for Bugs and 1,2,3 for Tasks, JQL will still fetch the value set on the fields, and just identify the work items with the corresponding value.

We have a video for field schemes here (along with other summer release features!) if you haven't had the chance to check it out yet: https://www.loom.com/share/693c7971fbfc412aa4286c78a6bec010