New field scheme issue

[Lalithya Raj]

Hello, 

In our company we use standard practice template for each business unit and before field scheme we had around 20 field configuration scheme and after the implementation of field scheme it has been raised close to 200. Is any team facing this issue? 

[Jason Krewson]

Are you talking about the new field scheme that is rolling out right now, details in this article Say goodbye to field configuration schemes and hello to the future of Jira ?

If so the change hasn't happened for my site yet. 

But if so I would recommend reaching out to Atlassian Support as that sounds crazy! 

If not can you expand on the issue you are seeing? 

[Lalithya Raj]

Yes, new field scheme and its already been implemented.

[Jason Krewson]

That's awesome, hope I get it soon!

I still recommend reaching out to Atlassian Support

[Gabriela]

Yeah, you're not alone. This is the expected outcome of the Field Schemes migration, not something you broke, and plenty of context-heavy sites are seeing the same jump.

The migration keeps the exact same fields available in every space and work type you had before. A lot of your per-project field visibility was really coming from custom field contexts, and under Field Schemes contexts only set defaults and options - they no longer restrict visibility, the field scheme does. So anywhere two projects shared an old scheme but had different visibility from their contexts, the migration had to split them into separate field schemes to preserve it. That's how ~20 turns into ~200.

You can pull it back down. Field schemes can still be shared across spaces, and the new UI shows which spaces and work types each one covers, so point the ones that should match at a single shared scheme and drop the duplicates. Atlassian's acknowledged this for context-heavy sites and said bulk cleanup tooling and an admin agent are coming.

[Lalithya Raj]

For each business unit we have around 25 projects and had 1 field configuration scheme and now its 25 separate schemes , finding it hard to create one master template as we were using field configurations based on issue types. We do have a optimizer cleanup app but its not updated with the new filed scheme yet.

[Gabriela]

The per-issue-type part carries over into a single scheme, so you don't need 25 to keep it. In Field Schemes the work-type differences sit on the scheme itself as per-field overrides keyed by work type, so a field can be required on Bug, optional on Story, hidden on Task, all inside one scheme. That's the same behaviour you had when you split field configurations by issue type, held in one place now.

So for a business unit you can build one master scheme, set the work-type overrides on it, then assign all 25 spaces to it and drop the 24 duplicates the migration created. The reason it came out as 25 is usually that each project's custom field contexts gave slightly different visibility and the migration split them to preserve that. If those 25 were meant to be identical, pointing them at the shared master collapses it back down.

On the optimizer app, until it catches up with the new model you'd be doing the reassign-and-delete by hand in the new UI, which does show every space and work type a scheme touches so you can see what you're merging before you delete anything. Atlassian has also said bulk cleanup tooling and an admin agent are coming for exactly this, so some of the manual part should ease up soon.