How does the site optimizer determines unused fields in a field configuration scheme?

[Michael Brändel]

I wonder how the optimizer determines which fields can be removed in a field configuration scheme. 
I recently fixed many of our field configuration schemes, which had more than 700 fields (most of them exceeded the 700-field limit that Atlassian will introduce in February' 26). 

Even though many projects have fewer than 100 fields on their screens, the field configuration scheme still has three to six times as many fields. 

Which criteria are relevant for the optimizer to select which fields to remove? Or in other words: why does the optimizer still keep so many fields while they are not used in any screen or do not even have any values for the given project(s)? 

[Hari Krishna]

Hi @Michael Brändel ,

The Site Optimizer is intentionally conservative in how it identifies unused fields. It does not rely only on whether a field appears on screens or has current values in a project.

A field will be kept by the optimizer if it is referenced anywhere, such as in workflows (conditions, validators, post-functions), automation rules, JQL filters, dashboards, reports, or historical issues. Fields that are shared across projects or schemes are also treated as in-use.

Because the optimizer cannot safely guarantee that removing a field won’t break an existing configuration, it only flags fields it is 100 percentage certain are safe to remove. This is why many fields remain even when they appear unused at the project or screen level.