Announcing General Availability of Field Schemes

[#1]

Hi everyone! 

We are officially beginning the progressive rollout of Field Schemes, the new unified way to manage fields in Jira! After getting valuable feedback from you during our Open Beta, we are retiring the legacy "Field Configurations" and "Field Configuration Schemes" to simplify field management, especially for admins managing large-scale instances.

Here is everything you need to know about the new experience.

The New Core Concepts (TL;DR)

To make field management less confusing, we are streamlining how fields are configured across spaces:

• Field Schemes: This new single layer will be the source of truth for which work types a field can appear on within a Space. This replaces the multi-layered Field Configuration Schemes. Just like the legacy setup, the new Field Schemes UI will clearly display which spaces and work types are currently using a specific scheme.

• Field Contexts: Their purpose is changing slightly. They will no longer restrict field visibility in a given space or work item. Instead, Field Contexts will solely define a field's default values and available options (like dropdown choices). Because they no longer restrict visibility, every field will have a global context that cannot be deleted.

• Screens, Screen Schemes, and Layouts: These remain the final gatekeepers for what users actually see and interact with when creating or viewing a work item.

Note for Admins: You can still hide fields used for automation by keeping them off your Screens, and you can still create "Read-Only" fields by putting them on the View Screen but keeping them off the Edit Screen.

The Migration Process: No Action Needed!

The migration to Field Schemes is fully automated -admins do not need to take any action.

Our migration tool will map your existing setup and create new Field Schemes to ensure that the fields currently available in your spaces and work types remain exactly the same. As a bonus, the tool includes an auto-optimization step that will automatically detect and remove associations for fields that are completely unused in the associated spaces.

A full migration guide can be found on: https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/FAQ-amp-Reference-Guide-Transitioning-to-the-New-Field-Schemes/ba-p/3197911

Technical Impacts & API Updates Because this is a major architectural change, custom scripts or apps relying on legacy APIs will need to be updated.

• If you manage custom scripts or API integrations, please review the migration guide and access if changes need to be made.

How to Prepare

• Test in a Sandbox: We highly recommend spinning up an Atlassian Cloud Sandbox and joining the Open Beta to thoroughly test your custom scripts and preview the migration without risking your production environment.

• Look out for Enablement Materials: As the progressive rollout begins, our enablement teams will be releasing comprehensive documentation, and updated Atlassian learning courses.

Timing

• We know this is a big change, so we will be progressively rolling out over the next 6-8 weeks for anyone on continuous release tracks (and sandboxes).

• For bundled release tracks, we anticipate the feature to be available in September - this should give you ample time to test on your sandboxes, and update any scripts ahead of the rollout.

• We recommend switching to bundled release tracks temporarily if you need time for the change, as we are unable to manage individual requests.

A big thank you to everyone who has been a part of our early access and open beta cohorts who have helped to shape this feature. The programme is still open for Enterprise customer who wish to have their sandbox enabled in advance - please raise a request here: https://earlyaccessprogram.atlassian.net/servicedesk/customer/portal/891

Best,

Carol

[__ Jimi Wikman]

"Field Contexts: Their purpose is changing slightly. They will no longer restrict field visibility in a given space or work item. Instead, Field Contexts will solely define a field's default values and available options (like dropdown choices). Because they no longer restrict visibility, every field will have a global context that cannot be deleted."

I would not say this is a slight change, but a pretty big one.

If all fields are global after this change, then there are many, many fields that require an update, as the context has been the way we both filter out what should be shown for what, but also to protect from global incidents.

If someone, for example, adds a named user in a custom field and that account is disabled, it will generate an error. In the past, we protected against breaking every JSM project, for example, by setting the scope. When we move over to this new setup, we will need to create new field schemes for every context, correct?

So I will see hundreds, if not thousands, of field schemes as we move over to this, as pretty much every custom field is configured with a scope today. That is a lot of new configurations and a lot of updates to keep track of when this hits.

Don't get me wrong, I think this is a good update, but it will change a lot of things and have a big impact, so it needs to be tested and verified heavily to ensure we don't break things in the migration.

Also, how will this impact exports if all fields are now global? Will the export function also use this new field scheme to only show the columns for the custom fields related to the search, or will I get every single field in the export as it is today if you don't add scope? 

[Rune Rasmussen]

We are looking forward to this simplified way of managed fields.

I am unsure about the changes to contexts though.

If today I have a single-select drop down field called Locations that a list of all our locations (offices, warehouses, outhouses, henhouses, doghouses, etc...).
The default context has all locations.
The IT context only has offices and warehouses and only applies for the IT Space
The Farmer context only has henhouses and doghouses and only applies to the Farmer Space.

This saves us from having many different fields with the same name.

How will that work if contexts are no longer going to restrict visibility?

[Juan Carlos Pin]

This brings simplicity to new setups, but we will need to be careful and double check what's now in prod.