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

[Varsha Mungale]

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. 

Thanks 

[Robin Milam]

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.

[Chris Rogers]

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?

[Pavel V]

Hi @Chris Rogers the optimizer is looking at both:

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

Hope this helps, P