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

[#1]

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.

Sign up for the EAP

[Dirk Ronsmans]

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!

[Brita Moorus]

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! ✨

[Lior Pinelis]

@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?

[Paul Pasler _Seibert_]

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):

1. 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.

2. 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.

3. 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?

4. 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.

5. 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.

[Julia Foden]

@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?