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.
@Carol Low - I second third @Brian R's thoughts here. It'd be immensely helpful to provide aliases in Jira / JPD spaces similar to how JSM allows aliases via Forms.
Hey @Carol Low is there any update on when the team-managed and discovery fields will show in the Fields section?
Also, an alias like @Brian R mentioned and @Stefan Draber & @Josh elaborated on would be really helpful. A contextable name that shows when working in a specific space to replicate what is in the JSM portal and forms would be amazing. Any given name should never be able to conflict with an existing field name across any of its contexts and people can be steered towards the best global field for their use-case. There are times where it makes sense to have separate fields, but also times where the name of something that exists is actually the better fit to be the global common language (yet the team might really have a preference to use their own term while working).
@Carol Low love the new changes and want to take advantage by cleaning up unused fields.
When I display a list of fields, I sorted on Spaces. I attached an example. If a field is not used in a space (None) and then there's a date in the column Last Date Used. How should I interpret that information? and if a field is locked, does that mean it's a default Jira field?
Atlassian Team members are employees working across the company in a wide variety of roles.
January 27, 2026 edited
@Brian R@Stefan Draber@Josh - We haven't given much thought to aliases. Thank you for the insights, I will have a look into this. I know for request forms there is a way to do this already (and assumed so for advanced forms too) but that is more only for the customer portal and the field name is still consistent within the system.
I do have one question though - would you use that date consistently in all your reports and JQL? or would you end up having to query it by alias name all the time anyway. (In which case, a different field seems less unwieldy, thinking out loud)
@Greg D - The fields are already in the Fields page! If you still don't see it can you raise a support ticket?
@Lauren Pennisi - The count of fields in a space is through either the inclusion of it on a screen of the company-managed-space, or the work type of the team-managed-space. The field is still usable through other interfaces like List or APIs (we are updating this column to be more accurate as part of Field schemes changes - see this article if you haven't yet had a chance to).
If a field is locked, Jira or another App has created it, and there's limited actions you will be able to take on it.
@Carol Low I confirmed with support that the team-managed fields/discovery fields experience has not yet been enabled on our sites since ours are very large and complex. Hopefully we will receive it soon so we can track down a bunch of duplicate fields that do not have values (we cannot figure out where they are via JQL and would need to go into every team-managed space manually right now). Figured I should just relay this in case anyone else watching this post is in the same boat (should be coming for us).
For your other question, I think the same name in reports would be fine since the aliases are generally needed for how a specific team wants to label the field while working on the work item (an example could be a field that globally is known across the company and thought-of in reporting as Release Date, but then each team wants to call it something else: Launch Date, Go-Live Date, General Availability Date, Ship Date, Deployment Date, Effective Date, etc.). There could be cases where we do want a few fields that have similar, but different meanings, but there are also many times where people are using synonyms and it makes it hard to know what the true metric to measure on should be.
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.
@Carol Low ideally, JQL and the Fields Admin page would support both the "official" field name and aliases. For example, let's say there's a field called "Department" [cf12345] that is used in different spaces for difference purposes (e.g. "Requester Department", "Responsible Department", "Sponsor Department", and so on).
When using JQL, typing in "Sponsor Department", there could be an intelligent suggestion for Department - cf[12345] (Sponsor Department).
In fields admin, there'd ideally be a second column that shows Alias values for the field.
I will select the columns I want on the view, but (sometimes) on subsequent visits to the Fields page, it reverts back to only displaying the originally selected 3 or 4 columns
Is this a known bug and will it be addressed?
Can an identifier be added to show which fields are system fields vs custom fields?
I thought maybe the field Id could be used for this purpose, but there are system fields that have "customfield_#####' values (i.e. Flagged, Sprint, Rank, etc.).
Something I just noticed (probably not related to the new UI) is that the Story Points field can be deleted.
I would've thought this was a system field that couldn't be deleted.
How much would this screw things up (sprints, reports, etc.) if someone did this?!?
Can an identifier be added to indicate if a field is specifically a JPD field vs a Jira/JSM field?
Are there any plans to consolidate the JPD Global fields UI within this main Fields UI?
It would be great to be able to admin all fields from a single place.
I'm in the Field schemes EAP.
Within the Field Schemes UI, the description is clickable and will open the corresponding fields Advanced settings dialog.
Any chance that ability will get added within this UI?
@Gary Spross you stumbled onto a piece of the puzzle that led to the painful creation of Story point estimate in Team-Managed spaces (originally Next Gen projects). I think there were some other reasons, but I believe the fact that the real field is not locked was one of the drivers.
I wish that there was an easy way for Atlassian to just lock the actual Story Point field instead of introducing that imposter (and a lot of other similar things in Team-Managed). Carol probably knows better, but I think there were Atlassian customers that did delete the real Story Point field and bringing it back was also painful (not sure why an admin would do that, but I guess Murphy's Law). One day, maybe the two fields can be truly merged.
@Greg D, don't get me started on Team-managed spaces... I love Jira Product Discovery, but am not a fan of being built in the Team-managed space style. I really wish a Company-managed capability would be introduced for that app.
The biggest thing for me is consistency. Consistency with menu options, features, capabilities, etc. I guess I'm getting off topic from the original purpose of this thread though, so I'll keep my remaining thoughts to myself for now...
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.
good question! I think the field should be accessible by its alias, because otherwise it's going to be a mess to work with it in filter querys, automations and so on.
Imagine you have a field that is labeled "Sponsor Department", but the actual field's name is "Department". How could you now that, even more so when you're not a Jira admin but a normal user or project admin with no access to the field and context configuration.
So, it would be required to find and access the field by searching for "Sponsor Department".
Are there any future Atlassain Admin and Jira Software plans to integration ServiceNow Resource Manager to synchonize the ServiceNow Resource Manager Groups as an Atlassian Managed-Team (Official Team) and the ServiiceNow Resource Manager Group roster members within its corresponding Atlassian Managed-Team (Official Team) as members?
In addition, how does Jira Plans leverage the Atlassian Managed-Team (Official Team) and its corresponding Jira system field called Team?
Atlassian Team members are employees working across the company in a wide variety of roles.
February 9, 2026 edited
Are there any future Atlassain Admin and Jira Software plans to integration ServiceNow Resource Manager to synchonize the ServiceNow Resource Manager Groups as an Atlassian Managed-Team (Official Team) and the ServiiceNow Resource Manager Group roster members within its corresponding Atlassian Managed-Team (Official Team) as members?
In addition, how does Jira Plans leverage the Atlassian Managed-Team (Official Team) and its corresponding Jira system field called Team?
re; ServiceNow Resource Manager - there are no plans for this yet. We're currently focussed on adding more permissions for Teams. However, I would love to hear your use case. Is this where your source of truth for Teams is and would you only be looking to sync the membership to this?
In addition, how does Jira Plans leverage the Atlassian Managed-Team (Official Team) and its corresponding Jira system field called Team?
Jira Plans supports Atlassian Teams i.e. if you create any Atlassian Team, it can be used across the products and in Jira Plans. 'Official' Teams (formerly known as Managed Teams) are a type of team that can be use here to identify that this is a team that is approved by the admin i.e if you wanted a distinction between end-user created teams and and 'approved' teams that can be used in connections to work.
We are a ServiceNow customer and currently leverage ServiceNow Resource Management (RM) as our system of record for Agile team management. Below is an overview of how we use ServiceNow RM today and how we are looking to integrate with Jira Cloud.
ServiceNow RM – Current Use Cases
We use ServiceNow RM to:
Establish Agile Teams Define Agile teams and maintain the team roster, including member roles and other key data elements.
Align Teams to Product Domains Map one or more Agile teams to a Product Domain. Domains represent technology or business focus areas, such as Health and Welfare Products, Payroll Products, Engineering Services, CRM, and Corporate Services.
Time Tracking Require Agile team members to submit weekly timesheets through ServiceNow.
In addition, our Portfolio Management Organization uses ServiceNow Strategic Portfolio Management (SPM) to manage portfolio projects. Projects are categorized as CapEx or OpEx for financial reporting purposes.
ServiceNow RM is the authoritative source for Agile teams and team membership.
Planned Integration with Jira Cloud
We plan to develop an integration between ServiceNow and Jira Cloud to synchronize Agile teams and team membership from ServiceNow into Jira as Atlassian admin‑managed teams.
Within Jira, these teams will be used for:
Jira Plans
Identifying the team responsible for Jira work items
Today, this synchronization is a manual process.
Portfolio Project Synchronization
We are also currently manually synchronizing ServiceNow Portfolio Projects into Jira.
Every Jira work item has two required fields:
Team
Portfolio Project
Agile team members are required to populate these fields. This enables us to:
Correlate Jira work items to the team that delivered the work
Associate work items to a Portfolio Project
Distinguish between OpEx and CapEx work for financial and reporting purposes
Lastly, we are researching how we can help our Agile teams to simplify their Jira backog and sprint activities to their weekly timesheet in ServiceNow based on the Jira work item and the corresponding Portfilio Project Jira custom field.
Please let us know if you need any additional details or would like to discuss this integration approach further.
115 comments