Announcement: Changes to field and work type configuration in Jira Cloud

[#1]

To support performance and allow Jira to scale, we’re releasing changes to field and work type associations.

Please feel free to leave any questions/comments/feedback below.

Work type configuration changes

Allow editing the Default work type scheme / Adding new Company-managed work types will not be added to the default work type scheme

Jira today associates every newly created work type to the Default work type scheme. Additionally, work types can't be removed from this scheme. We are going to change this limitation in two stages:

• Starting in July 2025, we will allow Jira admins to add and remove work types from the Default work type scheme

• Starting in January 2026, we'll no longer automatically include newly created work types in the Default work type scheme.

  • New work types created in Jira won't be automatically added to the default work type scheme

  • New work types created via the REST API Create Work Type won’t be automatically added to the default work type scheme

For convenience, we will add a new dropdown and allow admins to select which scheme to associate to:

This dropdown will automatically set to the "Default work type scheme," ensuring a consistent flow, similar to the previous setup.

Bonus: Jira settings now display a list of projects associated with the “Default work type scheme”, instead of “Global (all unconfigured projects)”.

Prevent deleting work type scheme that has associated projects

Currently, Jira allows deleting any work type scheme. If there are any projects associated with that scheme, those projects will fall back to using the “Default work type scheme”.

We will implement this change in two phases:

• Starting in May 2025, Jira will prevent deleting a work type scheme if at least one project is associated with it. If you want to delete the scheme, you need to migrate all the associated projects to a different work type scheme first.

• Starting in January 2026, the REST API Delete Work Type Scheme will prevent deleting a work type scheme if there is at least one project associated to it.

Optimize work type scheme

We’re releasing tools that identify and remove unused work types from a scheme, with just one click.

Field configuration changes

Adding and removing fields from Field Configuration Schemes

We’re introducing the ability to add and remove fields from field configurations:

• Removing a field from a field configuration functions similarly to hiding it, making it unavailable to projects associated with the field configuration scheme. However, a key difference is that when a field is removed, its configurations (e.g. descriptions) are not preserved and will need to be entered again if the field is re-associated.

• Adding a field to a field configuration is similar to showing/unhiding a field. It becomes available to the projects associated with the field configuration scheme.

Field associations can be managed in the Jira admin panel or using the new field association REST API.

Explicit association of new fields

Starting from January 2026, new fields will no longer be automatically linked to all field configuration schemes. Instead, they must be explicitly included in a field configuration scheme to be considered available for use in projects using that scheme.

Optimize field configuration scheme

We’re releasing tools that identify and remove unused fields from a field configuration scheme (and field configuration), with just one click.

How does Jira decide if a field is used or not?

If a field is hidden in the field configuration, it will be automatically removed, regardless of whether it contains values or not.

• If a field is associated to a screen on a project (via screen scheme and work type screen scheme) then it is considered as used

• If a field has a value on a work item in the past 2 years, then it is considered as used

• If a field is a system field, or an app field, or a product field, then it is considered as used

• Otherwise, the field is considered as unused

Automated optimization

Starting from Jun 16, 2025, we're going to start removing unused field associations from your field configuration schemes. Although this will improve the performance and stability of your instance, it may also break some associations. The whole process may take a couple of weeks to run on all instances.

What happens to my project? How do I add a field back if I need it?

There will be no difference for most of the projects, but several APIs will stop returning the unused fields.

If the optimization is causing problems, you can add the relevant fields back in Jira admin:

1. Open settings using the cog wheel icon in top navigation menu

2. Select “Work items”

3. In the left navigation menu, locate “Fields” header, and click on “Field configuration schemes”

4. Locate the relevant scheme, and select “Configure”

5. Locate the relevant field configuration and select the field configuration name

6. Select on “Add field” button, find the field and confirm

How is the automated removal different from the Optimize page?

If a field is hidden in the field configuration, it will be automatically removed, regardless of whether it contains values or not.

The automated optimization follows different rules than the manual approach:

Field	Automated optimization	Manual optimization
Is hidden (using field configuration)	Always unused, ignores all other rules	Always unused, ignores all other rules
Is associated to a screen	used	used
Is a system, or app, or product field	used	used
Has a value on a work item from the past 2 years	used	used
Has a value on a work item that has last been updated more than 2 years ago	used	unused
Is used in a workflow transition screen	used	unused
Is required (using field configuration)	used	unused
Has a non-default renderer in field configuration	used	unused
Has a non-empty description in field configuration	used	unused
Has been created in last 30 days	used	unused
Is associated to a project (via field configuration scheme) where the project has been created in last 30 days	used	unused

Default field configuration scheme looks like a real scheme

Jira always had an implicit default field configuration scheme. One could see it in project settings (and, confusingly, it was called “System Default Field Configuration”, even though it’s a field configuration scheme, not a field configuration). In the settings, Jira used to pretend that this scheme did not exist.

Now, the scheme is named “Default Field Configuration Scheme” and is visible in both project settings and global settings. The scheme is not editable and can't be deleted, but it can be optimized using the streamlining tools.

API changes

See this changelog entry for list of API changes: https://developer.atlassian.com/changelog/#CHANGE-2527

I have a question about this change

If you have any questions, comments or feedback, just leave them below!

[Izabela França]

Hi Pavel,

I have a question regarding the Field Configuration Schemes - If new fields will no longer be automatically linked to all field configuration schemes, does that mean that when I create a new field I should add it to the field configuration scheme first and also add it to the screen to be available in my project?

Thank you!

[Pavel V]

Hello @Izabela França, yes that is correct! You will need to add a new field to both screen, and a field configuration scheme, to make it visible on a work item.

We are preparing some changes to the field create experience to make this new step more apparent. Stay tuned for future announcements :)

Pavel

[James Rickards _SN_]

This is a welcome change for smaller or less mature organisations.

Can you let us know what sort of warning we as Admins will get before fields are removed from a schema?

Since the introduction of project admins being able to edit the fields they see via layouts, I've deliberately avoided having more than one field schema in a Jira instance, and occasionally setup an instance with one per issue type.  This ensures consistent use of fields which helps with centralised reporting. Thus, I don't see much of an impact to my life as an admin from these changes, but I expect the motivation is more to do with saving compute and data storage costs, which will hopefully keep fees low.

[Pavel V]

Hi @James Rickards _SN_, this post is the only warning that is coming. Do you have some concerns about the removal? What actions were you hoping to do after receiving the warning?

Pavel

[James Rickards _SN_]

Hi @Pavel V ,

Atlassian's Change Management standards has seriously deteriorated if this is the only planned warning.

If I'm reading this right, you're going to change configuration to automatically remove fields from field schemas, and you called out that this would impact APIs responses. and this will happen at some random date with the only notice being a post in a forum most Admins won't see?  I can also foresee several other things breaking such as saved filters that may have included the removed fields suddenly breaking.

Whilst the risk of impact is negligible for my current employee due to how I design schemes, I'd expect at the very least a reminder article closer to the date of the cleanup (for the newer admins who may not get an email to this one) and ideally a banner for admins pointing to the article. Ideally the banner a link to a page where admins can preview the upcoming changes to their config enabling them to be pro-active in changing any scripts/filters/dashboards that leverage the API and expect those fields to be available.

Please don't set yourself up to writing an apology like this one... https://community.atlassian.com/forums/Jira-Service-Management-articles/Changes-to-transition-screen-comment-behaviour-in-Jira-Service/ba-p/2941527

[Pavel V]

Thank you for the feedback @James Rickards _SN_ 

[Susan Waldrip]

Hi, I'm wondering about the fields being removed from the field config scheme in this situation:

If a field has a value on a work item in the past 2 years, then it is considered as used

What if the work item is older than 2 years, will the fields be removed? What happens to the data in those fields? We use the Standard version of JSM and don't have the option to archive work items, and we need the "old" work items for analytics since our help center is new and we won't have enough data to identify trends after only two years.

Will the fields (and their data) also be removed from archived work items?

Thanks for following up on these questions.

[Pavel V]

Hello @Susan Waldrip! Removing the field association does not modify the data on work items. So if you (or Jira) remove a field, then add it back - data on work items will appear again.

Pavel

[Yatish Madhav]

Hi @Pavel V 

Thanks for this article.

It seems the streamlining tools for the one-click solutions and clean up and the de-linking into in isolated scheme would be great! We have a lot of projects that we shared schemes for previously and, over time, needed to make a project independent of others so had to isolate schemes seperately - am i understanding that this will help our use case?

Also, "How does Jira decide if a field is used or not?" heading is twice - might want to merge and simplify/clarify that?

If I watch this post, i am assuming it will keep us informed of new developement and changes in roll out dates and updates, if any, right?

I really want to be on top of this if it means better performanace! I appreciate and agree with @James Rickards _SN_  too

Thank you

Yatish

[Pavel V]

Hello @Yatish Madhav , yes you are correct, the "Isolate scheme" action is doing exactly that for a single project.

"Divide all projects" will isolate all projects in the scheme in one go if you would like to do that. It may decide to group projects together and create fewer schemes than the one-by-one option.

Thanks for spotting the duplicate title, I updated the post. I will also post updates here as we roll this out.

Pavel

[Samuel Segaud]

Hello,

Do the optimization tools correspond to "Site Optimizer"? If so, will they be available only for enterprise plans?

[Pavel V]

Hello @Samuel Segaud , the tools showed in this article are going to be available in all editions.

Pavel

[Yatish Madhav]

Thanks for that

 @Pavel V  - i look forward to this and it's updates.

I do also dread it a little bit due to the breaking changes / permissions it may bring.

In our instance where we have just under 1000 project and 100s of schemes ... this clean-up and optimizing tools is very welcome! BUT also, would like to see it in action and have very very clear routes to take if there are fixes/actions needed by admins

Thank you

Yatish

[Samuel Segaud]

Thank you for your reply @Pavel V. Do you know whether the tools are currently being deployed or are in the process of being deployed?

[Pavel V]

@Samuel Segaud we're in the process of rolling it out, you may notice some of the smaller changes available on your instance today. It's going to take a couple of weeks to reach everyone.

[s_weber]

Hi @Pavel V , 

with these changes at the core, will Atlassian also commit to a Leading attribute for Custom-fields??

For Custom fields, sometime the ID is leading, and sometimes the name is leading (like in Automations, screens, filter-columns), making identification of fields with same or similar name difficult.

Also seeing ID behind the name would be an option, but currently in Automation's is impossible to work with multiple fields and the same name.

Having two fields with the same name is not so uncommon, sometimes we need a select field with single select in one project and multi select in another which has the same name. Adding single or multi to the name, is not useful and confusing for users. 

Thanks & BR

Sascha

[Josh]

@Pavel V is there any way for admins to see what is getting auto-removed?

• Starting from Jun 16, 2025, we're going to start removing unused field associations from your field configuration schemes

We greatly appreciate the focus on streamlining and improving these configurations, but this part has me a bit worried:

• Although this will improve the performance and stability of your instance, it may also break some associations.

If you might break some of our configurations, we should at least know what is getting broken so that we can respond accordingly. Otherwise, it's like throwing a grenade in our instances telling admins "good luck fixing all of this".

In addition, potentially breaking changes should likely be communicated in more than just one long article. My team and I are quite vigilant monitoring for platform changes, but we somehow missed this article until today. Ideally, the most critical items would be highlighted in multiple channels.

[s_weber]

I completely agree with @Josh , I would have not known or this potential break, without stumbling across another article from Carol. We 100% need to be able to see what will break so we can act accordingly.

I think one key aspect is generally not fully considered in SAAS products.

The customer does not own the product, but he does own the data. A customers Data is not a playground. It feeds in some cases crucial and critical processes keeping companies running, which leverages the spending of $$$ for the SAAS Product. 

So "Breaking" a few things here and there, may have a huge impact for some. Transparency and a head's up, is essential!

[Bernd Gurn]

Is this change also impacting Jira Service Management or only Jira Software?

Regards, BeGu

[Pavel V]

Hello everyone! Thanks for your comments.

@s_weber I am not sure if I fully understand your suggestion. What would ID leading and name leading look like? Can you please elaborate?

What comes to my mind, as maybe related, are two things:

Have you yet had a chance to read the announcement by Carol? We’re improving Fields management in the Admin pages of Jira the fields page will show a field ID, is that helping?

Second, Automations: we are aware there are certain difficulties with Jira fields in Automations and we are looking into it. At this moment however I do not have a specific information or release date to share.

Now for the associations.

We have been running on auto-removed Jira internally for a month with no problems.

At this point there is no scenario that I am aware of, that will actually break anything. But also we can't guarantee that we have found them all, therefore the disclaimer.

Details are in the table in the article above. Effectively we are removing the associations that Jira had created automatically, without anyone asking for it.

But yes, with all that said, I understand your concern, it's a big change. A change that we are making in your database.

If you have a specific Jira instance in mind, please feel free to message me on pvanecek@atlassian.com with details (do not share your URL in the comments here) and I can share with you a preview of the removal, or put your instance earlier (or later) in the rollout process.

@Bernd Gurn this will impact all Jira products.

Happy Friday the 13th!

Pavel

[s_weber]

Hi @Pavel V  sure, I can.

So for Automation, the Field-ID seems to not be the main marker / leading attribute, when interacting with custom fields. It is the name, thereby the current limit is just a logical consequence.

Ideally, it would be the ID, and store the ID in the JSON / configuration, but render the Name of a Field in the UI. Currently: Not the case. Adding the field as a supporting attribute visually, would also help.

Same goes for screens (at least visually to the user), if I want to add a field to a screen, again the name is the leading object, I have no way to differentiate by ID in any possible way.

The same goes for JQL. Selecting a field in Basic search, the Name and field type is leading when switching to JQL. The ID is nowhere to be seen. Also the JQL seems to not be stored in layers (store the ID of field, render the name on the UI), which can be seen by the huge side-effects of changing the name of a field.

We would see a huge benefit, if the actual ID of the field would become the leading attribute when things are configured & connected. Adding the ID as a supporting attribute in the UI, when working with fields on Screens, in JQL, in Adding fields to a column, selecting a field to adopt in Automation, selecting a field in a postfunction / validation / condition, is always a benefit.

I hope this helps to understand my point. If not, let me know.

Thanks & BR
Sascha

[Pavel V]

Thanks Sascha, I now understand what you mean. Some of those changes will be easier than others. I'll see what I can do.

Pavel

[s_weber]

Hi @Pavel V  awesome! Let me know if we can assist or answer questions!

[Phyllis C]

As a 5 year old Jira system admin, my only question is - what take you so long to offer these improvements in this area. :-) cheers! 

[P_D_ Foerster]

First of all thanks for optimization / clean up efforts.

I have some follow up questions:

1. After all mentioned changes are rolled out I want to add a new custom field to all or at least many field configurations. I would now have to write a script to add this to all affected field configurations. Will there be some sort of bulk action in the UI to achieve the same?
   I know at least one customer who uses shared schemes as well as dedicated schemes which results in not only 10 or 20 field configurations.
2. Why is the manual optimization different from the automated one? For example "Is required (using field configuration)" is considered used for automated optimization but unused for manual one. As an admin this doesn't make sense to me because if a field is required I expect that it is important for that work type / project. Another example being the rule "Is used in a workflow transition screen". That rule would only make sense if the field in question is not required and values were not set / updated in the last 2 years like in the other rule.