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.

[Julia Foden]

@Rune Rasmussen 

@Carol Low confirmed in a reply to me here that we will still be able to have multiple 'sets of options' per field. 

[Carol Low]

@__ Jimi Wikman 

We handle the move of data to maintain visibility in our migration - yes this may mean a lot of schemes are created - if you join the Open Beta using a sandbox, you will be able to see exactly how many new schemes will actually be created. We have a lot of customers in early access with a lot of contexts set so you aren't the only one. The migration logic minimises the number of schemes created as much as possible - i.e. it doesn't blindly create a new scheme per context. 

We know it may seem like a lot to manage if the number of schemes get out of hand, but we are working on ways to make updates to many schemes as easy as possible, including an Admin agent that we demo-ed at TEAM 26. 

With exports - can I confirm that you mean from the filters view? I'll have to look into it, I wasn't aware that it is affected by scope of context. 

@Rune Rasmussen , confirming what @Julia Foden mentioned is right. It only changes the visibility aspect, not the capability to have different default values and options. I will update the main post to make this clearer!

@Juan Carlos Pin - after the migration, end users will see no difference in fields, but agreed that if it's been set up not so cleanly in the past, that will remain - we do think this will make it easier to clean up though!

[Juan Carlos Pin]

@Carol Low Thx for the clarification, I guess it will be a question of order and tidiness.

PS.Admin agent sounds like music to my ears 🎵🙂 (where could I find that sessionto review that? thx!!)

[Susanne Harelius]

Oh I will for sure miss the visibility thing. VERY useful to keep the number of schemes down - and the maintenance/alignment burden down. 

[Carol Low]

@Juan Carlos Pin - I had a quick browse and didn't see the recording on the on demand library yet - I'll update you if it becomes available!

@Susanne Harelius I hear you - we are conscious that previously a lot of schemes are kept the same, but recently with the introduction of limits in fields, we think the trade-off to have a single place to understand the number of fields and to maintain is still worth it, even with more schemes to manage. 

[Becker_ Rene]

For me I greatly approve the change. The multi-layered approach was very difficult. to explain to trainees and done wrong almost all the time, while the use was ... limited (for us at least).

You wrote, that you tested and scripted to migrate smoothly. I appreciate that. But I already made bad experiences with mass updates via Atlassian and will remain sceptical. Please be the one to break the pattern. Please do not forget about the large-scale systems and please not expect us to manually move field schemes after the update in mass. If so, also provide a mass update tool for us as well.

I wish you (and us) a smooth tranisition :-) 

Thank you for taking upon the task

---

All the best

[Andrew Culver]

We had many custom fields that were scoped to 1 or 2 spaces each. I've recently noticed these fields appearing in spaces they shouldn't -- I assume they're now appearing in all spaces, effectively losing the scoping we had defined.

This is going to be a huge amount of work to identify the previous scoping and re-apply, if we even can identify the previous scoping.

It's also making dozens of new fields appear on issues, which makes our site configuration look quite amateurish.

Someone really screwed up with this.

[Carol Low]

hi @Andrew Culver - I can see you signed up on the EAP using your sandbox, and a different person signed up for your production site.

We had offered different migration options during the EAP, so it's possible it was due to the other option being applied to your production site.

Can you please let us know which site you are seeing this issue on your EOI ticket? Link for your convenience.

*Note: edited after I found the production site EAP request.

[Benjamin Črnjak]

Hi @Carol Low ,

will this change include other improvements, such as fix for "multiple context per single space"? 
I know you mentioned that this change will leave fields with only a single default context, but will it be possible to define different description/field options for different Work Types within the same space?

Also, will this change in any way improve translation options for fields? For example, will it be possible to translate dropdown/checkbox/radio button field options?

When can we expect this update to be available for all users?

Thank you!

Benjamin

[Nicole Shepherd]

We have 10 field configuration schemes in our production environment.

Just got this enabled in the sandbox.

We now have 343 fields schemes.

Love this for us.

::cries in admin::

[Carol Low]

@Nicole Shepherd - This is possible for sites that heavily relied on field contexts to manage visibility (and we get it, it was very convoluted with field configurations and field configuration schemes). We've shifting where this management sits, so you should have to worry about field contexts less from now on.

Before everyone panics, this will affect each site differently based on existing setups. Many of you have told me that you've inherited sites with messy configurations. This change has the effect of making the mess more visible, but our hope is that it can now help with cleaning up and maintenance on the long run - as previously mentioned, we are working on more tools and an admin agent to help you make changes in bulk and clean-up. 

@Benjamin Črnjak - multiple contexts is a separate project that is in progress, please keep an eye out for updates in this group. Unfortunately I don't have an update for you on translations just yet. 

We're taking a slow rollout approach - so this will likely reach bundled release tracks in September.