I have a question regarding the "Default Field Configuration Scheme". I see that this scheme is now associated with every type of ticket - specifically we have Bug/Story/Task. For Bug type of ticket i need one custom field to be "required" and i do not want to put any validator on the Create workflow because that is a common flow. What is the way to get this done? Earlier i had 3 different field schemes associated with these 3 different types of ticket. That has got replaced with this default scheme.
I used the optimizer on three of our projects after reading the description of how it works. It did clean up a lot of old, unused fields, but it also removed 11 fields that we actively use every day. I only realized something was wrong when QA reported they couldn’t move a story into Acceptance—turns out the QA Engineer field had been removed. After checking our screens more closely, I found 10 additional fields missing.
I opened a support ticket, and the initial response asked whether I wanted an option to reverse the removal. While that would definitely help future users, my main concern is that the optimizer removed fields that were still in active use. I’m hoping Atlassian can address the underlying issue so the optimizer doesn’t incorrectly classify fields as unused.
I'm not sure if there's been any updates on this, but @Robin Milam 's comment above leads me to believe that we can't trust the optimizer as much as I would hope.
It's speculation on my part, but I suspect the field/screen issue above was because the optimizer is checking screens that are part of the screen scheme space/project, but not checking transition screens in the workflow that's on the space/project.
How does this impact fields that are only referenced in conditional sections of forms that aren't heavily used? Same question, but for automations?
- fields that are referenced via transition screen in a workflow
- fields referenced via forms
If either of those is detected then the field is considered used.
As of today Jun 4th 2026 the optimizer does not check for "field referenced in automations" explicitly. What usually happens is that if a field is used in an automation then it has values on some work items, and/or it's also associated on a screen. Which the tool detects instead.
I think some of the confusion I have stems from the original post and the distinction between Automated Optimization and Manual Optimization; can you confirm that Automated Optimization refers to when Atlassian enforces the change, and Manual Optimization is when we use the Optimize page?
Can you also verify whether the original table is still accurate or has since been updated?
Field
Automated optimization
Manual optimization
Is hidden (using field configuration)
Alwaysunused, ignores all other rules
Alwaysunused, 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
If that table is up to date and Manual Optimization refers to the Optimize page, a field used on a workflow transition screen is flagged as unused, which seems to conflict with your response above (and there's no mention of forms). It would be helpful if the specific criteria were documented on the Optimize field configuration schemes page to help address this.
Are there any plans to incorporate more details in the optimizer's report for human validation? Showing which fields are used and where they would go would go a long way towards validating the optimizer's results and preparing accordingly.
I love the idea of having a button I can click to fix the hours of manual work this would normally take, but if it does so incorrectly, the button pusher (me) is the one who is on the hook for breaks and fixes :)
Thank you again for the information and discussion.
You can view the the list of fields that are unused during scheme optimisation and it is available as a CSV download for your review.
We have two optimisation levels - - Site level removal of unused fields across all spaces (permanent field archival) - Scheme level removal of unused fields in the spaces associated with the scheme (field disassociation, not archival)
The page linked above talks about the second optimisation (scheme level)
56 comments