Atlassian Team members are employees working across the company in a wide variety of roles.
December 13, 2025 edited
@Andrew Culver - You'll be able to do this through grouping the projects into Field schemes and only adding those fields into the Field scheme.
Since Field schemes will be more straightforward to manage than Field config and Field config schemes, it should be easier to manage relationships like this even without limiting visibility by means of contexts.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
1. Fields context are staying as they are with the ability to define multiple contexts per field, each can bee associated with multiple spaces/work types.
2. Existing field context, as such will be left in place as they are.
3. Field context will not define visibility/association of a field with a space, only the options that space will show for the field.
4. Visibility/association of a field with a space will be determined using the new Field Schemes only.
Questions based on the above -
a. If a field has no 'default' context associated with 'all spaces' context, but only context associated with specific spaces (doesn't matter if all work types of specific ones), and a space has this field associated via Field Scheme, what will happen? Will the screen appear at all? Will it have any values in case it's a list, for that space?
b. If a space is not associated with a field via Field Scheme, but the field has a dedicated context associated with that space specifically - I understand the field will not appear in any case?
I think a clear flow, or diagram elaborating more on how context and their association, together with Field Schemes association affects fields visibility, options and searchability will benefit everyone.
Atlassian Team members are employees working across the company in a wide variety of roles.
December 18, 2025 edited
@Shai Gilboa - you have understood it beautifully.
"If a field has no 'default' context associated with 'all spaces' context, but only context associated with specific spaces (doesn't matter if all work types of specific ones), and a space has this field associated via Field Scheme, what will happen? Will the screen appear at all? Will it have any values in case it's a list, for that space?"
- in this case, a new default will be created, and the list will be empty, as we feel that its not fair to assume which list to re-use if more than 1, or even if only 1 (we are seeking feedback on this). - during migration, we will set the field scheme for the field to be only available the work types in the previous context set. thus, the field won't become visible.
"If a space is not associated with a field via Field Scheme, but the field has a dedicated context associated with that space specifically - I understand the field will not appear in any case?"
- This is correct - but we are investigating if there are ways to prompt or automate the addition to field schemes when you create a new context for a space that does not have the field associated with the field scheme, to make this more seamless. To manage expectations, we have not planned to include this in the initial release, but again we are looking for feedback for this.
As for creating some diagram to illustrate - we will be doing this as part of creating up to date documentation for this, thank you for the feedback!
Atlassian Team members are employees working across the company in a wide variety of roles.
December 18, 2025 edited
To everyone,
Thank you for your engagement over the year, I truly appreciate all the feedback and passion from you all - it makes my work fun and worth it. I'm taking some time over the end of year now, so wishing you all Happy Holidays and see you in the 2026!
Not directly related to Schemes but more with Field Context.
One thing I've been struggling since always is field context merging/removal.
During transformations, cleanups and other actions, I have found myself having to export field values in CSV files and then import them back after context removal and this is a long taking task in some cases.
Context merging would be an amazing implementation to deal with these kind of tasks.
@Carol Low moving forward is there any way that there could be some visual demos to help us see how the changes will actually look when executing a field configuration?
These would really help those of us not within the early access program to see the changes and learn them before they go live?
@Carol Low I was quite skeptical at first, mainly with worries about impact. I agree to the change, should be a beneficial one, especially with simplifications and better / streamlined UI!
However, all common questions were answered with confidence, thank you :) We just signed up, we have been heavily using contexts to limit views, while re-using standardized screens.
We also often place a different description in Field Configurations, so It will be interesting how all of it turns out with the chosen migration path.
With a JIRA & Configuration history since 2011 and almost 200 spaces, I think testing how this goes is a vital step.
33 comments