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

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 _Spark-Nel_]

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 _Spark-Nel_, 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 _Spark-Nel_]

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 _Spark-Nel_ 

[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