Updated 14th May 2025 to include additional information on changes impacting work types and the rollout of automatic optimization of field configuration schemes.
Summary
In order to deliver reliable performance for Jira we need to make changes to how fields and work types are associated with projects, and improve how admins manage these associations.
| Change | Date |
|---|---|
| 1. Field Configuration Schemes will be automatically optimized | Jun 16 - Jun 30, 2025 |
| 2. Introducing the ability to add and remove fields within Field Configuration Schemes | Jun 30, 2025 |
| 3. Introducing streamlining tools to optimize field associations and work types | Jun 30, 2025 |
| 4. All new fields will need to be added to projects explicitly when created via API | Jan 1, 2026 |
| 5. Creating a work type will no longer add it to the default Work Type Scheme | Jan 1, 2026 |
| 6. Work type schemes that are associated with a project can no longer be deleted | UI: Jun 1, 2025 API: Jan 1, 2026 |
| 7. Allowing to remove work types from the Default work type scheme | Jun 1, 2025 |
What’s changing
1. Field Configuration Scheme optimization
In June unused fields will be automatically removed from schemes for all customers. Pruning reduces the number of fields associated with schemes by removing any fields which meet this criteria:
- Do any work items have values for the field?
- Is the field visible on any screen/layout in the project?
- Is the field hidden on the field configuration? (hidden fields will stop being displayed)
Fields that are not used will be automatically removed in order to significantly improve the performance of Jira.
2. 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. One distinguishable difference is that when a field is removed, its configurations (e.g. descriptions) are not retained and will need to be re-entered 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 via the admin UI or using the new field association REST API.
3. Streamlining tools
Tooling will be available to Jira administrators to assist with reducing the fields associated with field configuration schemes and optimising work type schemes. The new tools will allow admins to:
- Identify and remove all unused fields with a single click
- Create a new optimized field configuration scheme for a single project
- Identify unused work types per project for safe removal
- Split an work type scheme into a new optimized scheme
Using the streamlining tools should result in a noticeable performance improvement, particularly for tenants with a lot of custom fields or work types. We recommend performing streamlining as soon as possible.
4. Explicit association of new fields
New fields created via API from January 2026 will no longer be automatically associated with all field configuration schemes. They’ll need to be explicitly added to a field configuration scheme to be considered available for use within projects using the scheme.
5. New work types not added to default work type scheme
Work types created from January 2026 will not be added to the default work type scheme. They will need to be associated to the schemes for the projects where they are required.
6. Work type schemes associated with projects can’t be deleted
From June 2025 work type schemes will need to be un-associated with any projects before they can be removed from the Jira admin interface. This change will be applied in the APIs from January 2026.
7. Removal of work types from default work type scheme
We are adding the ability to remove work types from the default work type scheme. Giving better control of which work types are associated with each project.
Affected APIs
Changes are being made to the following APIs (deprecation notices with effective dates will be published):
- Get field configuration items: the isHidden property will ultimately be removed and previously hidden items will no longer be returned.
- Update field configuration items: requests with isHidden=true being set will result in a field association being removed if it currently exists. There is also a new Remove associations API.
- Edit issue: overrideScreenSecurity=true will no longer allow updating of fields that are not associated with the corresponding project.
- Replace issue field option: overrideScreenSecurity=true will no longer bypass field association checks.
- Create custom field: will no longer implicitly associate the field with all projects. It needs to be associated with the required contexts using the Create associations API.
- Create work type: will no longer implicitly associate the new work type with the Default work type scheme. Use the Associate work type to a work type scheme API to associate explicitly.
- Delete work type scheme: will return a validation error if the scheme is associated to one or more projects. Use Get work type scheme API (with the projects expand, and id query parameter) to get a list of projects. Next, use Assign work type scheme to a project API to associate all projects to another scheme and finally delete the unused scheme.
- Remove work type from work type scheme: allows to modify the Default work type scheme. Accordingly, the Add work types to work type scheme API also allows adding.
- Consequently, the Get work type scheme items API no longer guarantees that the Default work type scheme contains all work types.
Why the changes
Currently global fields are considered associated with every company-managed project, unless they have been hidden by an admin or have a scoped context.
Given that our APIs return much of a work item’s data by default, the payloads returned by our APIs are getting bigger, to the point where we see OOM (out of memory) errors on the Jira Cloud platform. The growing payloads are impacting the reliability of all of the systems involved. For example, it can increase response time when calling endpoints and result in rate limiting.
Therefore, we’re introducing mechanisms to reduce the number of fields associated with company-managed projects, without degrading the user experience.
Early access and feedback
We will be running an early access program for those changes so that you can test them ahead of time and provide your feedback.
Fill in our expression of interest form to register.