Say goodbye to field configuration schemes and hello to the future of Jira

[#1]

Starting in April 2026, we’re introducing a powerful new way to manage fields. We will be retiring Field configurations and Field configuration schemes, replacing them with a more unified experience called Field schemes. Be among the first to try it out – join our Open Beta in January 2026 to explore what’s new and share your feedback!

Sign up now

Hi everyone, it’s Carol back again with another exciting update on how you manage Fields in Jira!

My team has already updated the UI on the Fields page and brought team-managed fields to the Fields admin screen. Soon, we will be introducing a more streamlined experience called Field schemes.

The future of fields management

What are Field schemes?

Today, fields are assigned to Field configurations, which are then grouped into Field configuration schemes to define which fields appear in each space. We recognize that this structure can be challenging to manage, and that’s why we’re simplifying this and bringing these two concepts together into a single, streamlined one called Field schemes.

In case you missed it: we’ve posted updates in the Atlassian Developer community outlining how this impacts our APIs:

• RFC 105: New Field Scheme Model APIs for Field Configuration Backup, Restoration, and Management

• RFC-104: New Field Scheme Model APIs for Project and Work Type Associations

• RFC-103: Jira Field Configuration Overhaul: Admin Experience and API Changes

Updates to how you use Field contexts

Additionally, when we roll out field schemes, we will no longer use field contexts to restrict field visibility in a given space or work item. Field contexts will continue to define a field’s default value and available options.

Currently, admins often use Screens, Screen schemes, Work item layouts and Field contexts in a space to define what fields are available on work types. However, this approach has some drawbacks:

• Screens only control which fields appear when creating or viewing a work item in the full page view. Removing a field from a screen doesn’t remove it from the space. If you’ve ever seen unrelated fields that appear when you are trying to filter work, this is probably why.

• Field contexts currently have limitations that could lead to messy workarounds.

If you’ve been watching this space, this change is part of the foundation work we are doing to enable us to finally unlock the ability to set more than one field context for a single space - I’ll keep you posted when we have estimated timelines for this change.

TL;DR

• Field schemes will become the source of truth of what work types a field can appear on for Spaces.

• Field contexts determine default values of fields, and what options are available for users to select.

• Screens, Screen schemes and Work item layouts determine what users see when they are creating or viewing a work item in the full page view.

The migration progress

How we’re planning to migrate your data

We’ve set up a migration tool that preserves the current state of your site. First, the migration tool maps your existing setup by doing the following:

1. First, it reads your current field configuration & field configuration schemes, noting:

   1. the spaces in which these schemes are used

   2. the fields that are associated to those spaces, and

   3. the work types to which they apply

2. It then looks at your existing field contexts, identifying any work types or spaces that don’t have field contexts.

Once it has mapped your current setup, the migration tool:

• Creates new Field schemes that ensure that the fields currently available in your spaces and work types remain that way

  • Note: you may have more schemes than you began with fewer spaces associated with each scheme.

• Automatically associates this new Field scheme to the Space(s).

Timelines and what to expect

We’ve been in early access with a small group of customers and will open this up more broadly with our Open Beta in January 2026. If you’d like to join, please fill in this form and we’ll be in touch in January. If you’re already in the early access program, you’re all set – we’ll roll out the changes to you automatically.

We’re targeting to start progressively rolling out to all customers from April 2026. Joining the Open Beta helps you get ready early and gives us valuable feedback to make the transition as smooth as possible.

Thank you again for your support and interest – please feel free to leave any questions or comments below.

Sign up now

[Dave Mathijs]

Hi @Carol Low Can you please clarify:

"When we roll out field schemes, we will no longer use field contexts to restrict field visibility in a given space or work item." vs. "TL;DR Field contexts determine default values of fields, and what options are available for users to select."

It's not clear to me whether Field contexts will remain or not.

[Alex Koxaras -Relational-]

@Dave Mathijs Field context will remain, but only to determine default values. But you will not be able to to restrict field visibility in a given space or work item. That's pretty clear.

@Carol Low call me old school, but I don't like it. :/ 

[Julien Béchade]

This is a welcome update @Carol Low and I'm sure hardcore Jira admins will probably disagree but field configuration is a struggle for a lot of people because there are too many layers and it is hard to grasp how they relate.

[chihara]

https://jira.atlassian.com/browse/JRACLOUD-95298 will be implemanted ?

[s_gridnevskii]

I don't like it. Admins used field contexts to hide fields users should not see, e.g. some data used in automation. It also added flexibility - e.g. if you even do not want a field in another space you could make it invisible for users and share field scheme between several spaces. I understand that you want to make it simpler, but now I will have to make field configuration for each issue type for each project, it can be 10 configurations x 200 spaces = 2000 field configurations. What a mess.

One more concern. Now my project shows me in how many projects the field configuration schema is used. If users require incompatible changes I copy the scheme and apply it. After the change I need to be sure that field configuration for issue type in project is not used somewhere else before I change it. How it will happen in UI? It will list all projects and issue types where the field configuration is used? It will be a long long list if the configuration is popular.

So everyone will end up unique field schemes for each issue type in each project. Or vice versa will use one configuration for all projects and issue types. Both variants are a mess, especially in large organizations.


Perhaps a better idea would be to untie custom fields from jira and allow to create them in terms of a project. Then we do not need field configuration at all. When creating a project users will tell admin what fields they need and he will create them right there in the project without a fear that he breaks something in other projects. If someone needs exactly same project he will copy it and fields will be created anew for this project. Users will be able to search issues in several projects using field names.

[Jaime Capitel _Sngular_]

This is brave, difficult (because of the change management involved) and super valuable initiative. Kudos and hope it sets a precedent!

[Julia Foden]

Hi @Carol Low 

Similar questions to others above regarding field contexts. You said

Additionally, when we roll out field schemes, we will no longer use field contexts to restrict field visibility in a given space or work item. Field contexts will continue to define a field’s default value and available options.

Will it still be possible to have multiple contexts per field with different sets of options for different spaces? PLEASE SAY YES!! Will each context (set of options) still be able to be applied to multiple spaces if required?

You said

Field contexts currently have limitations that could lead to messy workarounds. 

What specifically are these limitations? The only limitation that springs to mind for me is that it's not possible to have different sets of options for different work item types in the same space. Will your change fix that?

And a general point, regarding statements like this: 

Screens, Screen schemes and Work item layouts determine what users see when they are creating or viewing a work item in the full page view.

 Screens and Screen Schemes also determine which fields users can edit. It is essential that we can configure our screen schemes such that certain fields are on the view screen but not editable. For example those field values are set in workflow post-functions or by API / Automation or in workflow transitions that are restricted to certain groups/roles. Please keep this in mind as you continue with your changes.

[Yatish Madhav]

Thanks @Carol Low  and Atlassian!

I am all for the simplification of the field management, in both the short term and long term with this update and migration.

I have not yet signed up as I am not sure what to select for the "How would you like your Field Schemes migrated" question as yet. How do you advise we check to make sure of what we select to join? I am very keen to join the EAP for our test and prod instances.

I also think short Loom videos of what this looks like and the various existing/new use cases around fields, contexts, and schemes would help existing and new admins alike. Hope that can be made available while this is in early stages of dev.

Really looking forward to this. Kudos!

Thank you

Yatish

[LAL]

My initial thoughts

[Andrea Mura]

They always change their tune; it's hard to keep up.

[Hugo Navia]

It looks pretty promising. However, I'm a bit worried o what this might mean for current scripts using the current legacy structure.

Are there gonna be changes to it I assume.

[Carolyn White]

@Carol Low Is it possible for one or two projects to join the beta group in January or is it all or nothing? We have a sandbox project in production that we would like to participate in the beta group before inviting others to join. This also gives me, the Jira SME, an opportunity to play with it without the whole department playing with it and making changes that can't be undone.

[Sekhar Reddy]

Hi @Carol Low 

Thank you for the updates regarding field usage and performance improvements.

I have a few concerns I would like to clarify:

Field Configurations: The main benefit of Field Configurations is the ability to maintain separate settings for different work types within the same space (e.g., making specific fields required for one work type but optional for another). Could you explain how we can achieve this differentiation with the new changes?

Field Contexts: as highlighted earlier by @Julia Foden , will it still be possible to maintain multiple contexts per field? Specifically, we need to ensure we can still have different sets of options for the same field across different spaces.

Your clarification on these points would be appreciated.

[John Dunkelberg]

As a DC customer soon to migrate to Cloud, I'm not clear on:

* How we will hide fields used in scripted solutions in this approach

* How we can make sure that fields which are not on a screen  are not set via other mechanism (Plans, Structures, API calls).  Consider the case of a field which is used on Epic in one department, but not another.

* If this will change the maintainability of an instance with 500+ projects (ahem *spaces*) which serve a half-dozen departments with different needs.

[s_gridnevskii]

@John Dunkelberg some time ago we were calculating the cost of Jira + Plugins and found out that it is much cheaper (for us) to have several instances. Simply because we have loosely coupled departments. Some people need plugin, some will never use it and we will pay for them. 

Seems like the same story. After changes we will need to have separate instances of Jira just because it will be too hard to have one Jira for all organization.

[Robert Eiser]

I like the direction in principle, and think simplifiying how we handle fields is a great direction for Jira.

I am also nervous about how this will affect our current configurations. Will I need to reconfigure all of our field configurations? Will users suddenly start seeing fields they shouldn't, creating confusion? Lots of unknowns right now.

The timeline of April 2026 for the transition seems very ambitious - this change will require some time for admins to digest and understand the impacts as well as the migration process. We will want to avoid is a change that suddenly requires us to rush solutions and patches (like with the move of the transition button).

I think a video of the changes would be helpful, at least to let us start familiarizing ourselves with what is intended, without the risk of joining a beta.

[Matt Doar _Adaptavist_]

The ability to have a dry run mode for the migration would be really useful to give admins a sense of what the changes will be, in their sandbox instance

[Carol Low]

@Dave Mathijs - Field contexts will remain, they will only set values on fields. 

@Alex Koxaras -Relational- - Would I be able to convince you to give it a try and tell us what you don't like about it? Your feedback will be valuable.

@chihara - sorry but https://jira.atlassian.com/browse/JRACLOUD-95298 will not be addressed in this release, we are keeping an eye on the interest levels on this request.

@s_gridnevskii - Just to clarify, you can vary issue type (aka work type) configurations within a single field scheme - I hope this alleviates at least part of your problem. I'd love for you to join the Beta so that we can have a look with you on the resulting data shapes to see how we can limit the extent of issues for you. 

@Julia Foden - Yes, allowing for more than 1 context per space is the plan, but it may not roll out at the same time, but followed up at a later stage.

The single context per space is the primary limitation.

We won't be changing whether fields are editable or not on the view screen as part of this change, it will stay the same.

@Yatish Madhav - if you aren't sure, the first option is identical to what I've described in this post, and I recommend it. Great suggestion on the looms, I'll look into it if I have the capacity to, thank you.

@Hugo Navia - The changes to the APIs are documented in the links embedded in the post, please review them to see if any changes are required for your scripts.

@Carolyn White - Yes - please sign up and I will set you up for this.

@Sekhar Reddy - "The main benefit of Field Configurations is the ability to maintain separate settings for different work types within the same space (e.g., making specific fields required for one work type but optional for another). Could you explain how we can achieve this differentiation with the new changes?" - this will still be possible within the scheme

Field contexts - Yes this is planned, I will provide an update on timing when I have more confidence on it.

@John Dunkelberg - "How we will hide fields used in scripted solutions in this approach" - Please review the API changes in the links in the post which should provide details on the new APIs that your scripts should be updated to use.

"How we can make sure that fields which are not on a screen  are not set via other mechanism (Plans, Structures, API calls)." - In this case we recommend different field schemes for the departments. Screens don't make sure that fields are not set via other mechanisms today.

"If this will change the maintainability of an instance with 500+ projects (ahem *spaces*) which serve a half-dozen departments with different needs." - In this case it can potentially be maintaining half-dozen field schemes. 

@Robert Eiser - You won't have to reconfigure your field configurations, our default mechanism will maintain the exact field visibility for end users. 

We are running test runs of the migrations for Beta, and if you are able to provide a sandbox or test instance, you can familiarise yourself early on. 

@Matt Doar _Adaptavist_ - That is the plan for Beta access :) 

[Julia Foden]

Hi @Carol Low 

Thank you for the responses but I think you might have misunderstood mine and Sekhar Reddy's question about multiple contexts per field. We are not looking for anything new, simply a confirmation that existing functionality will not be lost.

For example: a field called Classification has two contexts. One context, configured for projects/spaces ABC and CDE has options 'Small', 'Medium', 'Large'. Another context of the same field, configured for project/space XYZ has options 'Red', 'Green', 'Yellow'.

This is possible now. Can you confirm please that this will still be possible after your changes.

Thanks.  

[s_gridnevskii]

@Julia Foden from what I see in original post contexts will not have projects field anymore. If their migration code is wise enough it will copy the custom field and assign each copy to different configurations. If  migration code is stupid they will just drop all contexts for the field except one and your project CDE will display field with options for ABC.

[Carol Low]

@Julia Foden - You are right, I did misunderstand, thank you for repeating and clarifying it for me. Your use case is still maintained and possible - there is no change here.

[JG Meillaud _]

Hi @Carol Low ,

I understand the current situation can be improved, but this is making me anxious.

At the moment we use contexts to make a field only available to some specific ticket types. This allows to have a mandatory field only applicable to a specific ticket type while sharing screens and field configs.
For example I can have a "Root cause" drop down only apply to bugs and still have the same configs for Bugs and Stories in the same project.

How will I achieve this?

We also have some text fields with default values, that we use as input in create screens. With the current ability to restrict fields to specific ticket type through the context we can ensure that these default values only apply to types where the field is on the create screen so we don't have unnecessary default values all over our tickets.

How are we going to be able to do this?

[Carol Low]

@JG Meillaud _ - It's not in my screenshot, but you will be able to adjust the availability, required/optional, custom description for different work types as you did before. We are still testing out the UI, if you join the Beta you'll be able to try this out for yourself. We are planning to maintain all existing configurations so you should see the settings carry across. The location to configure those settings will just be moved into the new field schemes UI.

Secondly, I think you are asking about setting default value - this will still be done in the field context, and your migrated field scheme will restrict the field to the same work types as you set in your field context. So your default value you set will still apply, and the field will only show on those work types. So the end result should be no different for end users.

Further, you can still have default value set only for selected work types in a space - this is not changing.

I hope this answers your questions, if not, please reach out at clow@atlassian.com and I will be happy to chat further.

[Andrew Culver]

Glad that we'll finally be able to specify multiple contexts for a field in a single space.

If not with contexts, how will we limit visibility of fields? We have many fields which we want to only appear and "be in the context of" one or two projects. How do we do this now?

[Joao Zampa]

@Carol Low 

I hope that this is a step closer to allow us to give Project admins more ownership and flexibility when it comes to managing fields that will only impact them.

The ideal scenario, which would alleviate a lot of admin work, IMO is:

• A project admin can update any field that has a designated context to their project.
• A Project admin could use add an existing field to their project and if needed, would be able to create a new context for that field so they could manage it

Thanks!