8c82428f765f _ thanks for raising this and letting us know - we will look into it.

Yes this is critical for my JPD workflow. Please add 

0b5d81b92926 - Parent Link field is being replaced by Parent field which is shared – you can read more about this [here|https://community.atlassian.com/t5/Jira-Software-articles/Introducing-the-new-Parent-field-in-company-managed-projects/ba-p/2377758.]

haddonfisher - thank you for the feedback around Jira Product Discovery, it makes sense to me. We have taken note of it and will take it into consideration as we evolve the product!

684cb16ed833 I can think of a couple use-cases where I would want data that exists in a JPD field to be the same as on JS or JWM issues. One big one off the top of my head would be around things like the "Team" field, where I have lists of teams or teams-of-teams who are involved or interested in a JPD idea; that shouldn't need to be maintained in two places. The other "meta" use-case is around reporting; I can think of a couple of fields I'd want to be able to search for which would include JPD+non-JPD projects.

The bigger question though is if JPD fields are not instance-wide, can they be shared across JPD projects? This would be a tremendous limitation for people working in scaled Agile environments, because otherwise they would need to centralize ALL of their ideation in a single project to maintain consistency.

At the end of the day, I guess I would just say "a custom field should be a custom field should be a custom field" - they all should work roughly the same and be usable in roughly the same ways. I recognize this is never going to be entirely true with team-managed projects, but let's not make it any more complicated.

What about other fields like "Parent Link" ?

Hey everyone, field sharing is now generally available across Jira Software, Jira Work Management and Jira Service Management projects! Moving this to closed. 

I use this feature for my Jira Software team-managed projects, which works as expected.  For my use case, I need JSM team-managed projects also to have this feature.  Is there an ETA for JSM?  Thanks.

Hi, what about Jira Product Discovery product? Are you planning to release this feature as well there? 

Really? I cannot find it.

So based on what is in the Description was this feature rolled out as of February 8th, 2023?

Hi c48be19ba6fe !

We are working on this and will be sharing in the Atlassian Community around the end of Nov. I'll make sure to link here too. Thank you for sharing what information you would like to see.

Regards

Carol

Hi!

Would someone from the Atlassian team please describe how you anticipate this change will work, including:

• where/how field sharing will be managed,
• impact to existing fields,
• migration strategy for existing team-managed projects' fields,
• impacts to automation rules,
• impacts to the built-in, very old, dashboard gadgets field usage,
• and so forth? 

Knowing this information will help the community of users and site admins anticipate the bending/breakage due to "decisions" around team-managed project usage.

Thank you.

Hi,
Is there any update regarding this? any new ETA?

@G, there's a few ways to read the original ask and I think I was less clear than I could have been:

• I do not think fields created for team-managed projects should be allowed anywhere outside of their project. If the ask is to allow this, then yes my vote would be -1 for the reasons above.
• If the ask is instead to make company-managed fields available to team-managed projects, then the risk to the rest of the application is a lot lower so go for it.

However I think we do disagree about the renaming. The problem I am trying to solve is less in search results and more in searching (or really anything tied to picking a field). Jira doesn't expect you to have 10 fields called "request type", so if you are picking from a picklist (say when building an Automation rule) you just see "Request Type" repeated 10 times, with no indication which one is the system one, which one is the custom field, and which are the team-managed ones.

haddonfisher hopefully Atlassian does find a way to allow contexts for a particular field within the Team Managed projects (to your point, these projects have been really messy since their debut and there are a few other things that need to be fixed).  I forget what Atlassian mocked up for duplicates, but if they are going to be allowed after this change, I think it is probably important to __ at least prompt the user that a field with that name already exists and probably allow the Jira admins to decide whether they want to even allow duplicates (even if it is just a match on name and not also type... people constantly pick the wrong field type for their use-case).

I would say that fully preventing duplicates and allowing the team managed user to spin up their own context for fields is the best way to handle it (allows for different field values in lists for each team if you need to utilize a Team Managed project).

Also, Haddon, I'm not entirely sure why you are saying that Atlassian should not proceed with this.  It seems like you just want them to add some features on top of this?  Maybe you are thinking that this is allowing Team Managed Project Admins to create global fields?  I don't think that is what they are doing... they are just exposing the already-created-company-managed Global custom fields created by Jira Admins for the Team Managed Project Admins to use (so sharing best practices from the people more knowledgeable on Jira administration).  A Team-Managed Project Admin could then decide that they actually need something new, and then create it, only affecting their own project... but they don't need to start from scratch and ruin the instance for everyone else with tons of the same exact field.

With your example where it appends project to the name of the field for use in the JQL, I think it would just make searching harder than it already is today.  Even today in the UI you can search by project in the parameters along with the field if you only care about finding values for a single project... and if you want to know all of the places where there is a shared value for a field between different projects, even right now you can search "Current Team" = Dev and it will find all of the results for every project, both Company Managed and Team Managed that have a list field with that name and that value.  At least right now we can align the Team Managed field types so that UI search finds everything.

The biggest gap right now is that via API you cannot integrate a field consistently (that is done via customfield id and it needs to be the exact same field to make that work and scale).  There are some fields that hold custom integration identifiers and it is very cumbersome to be able to setup and scale your integration into Team Managed projects without being able to see company-managed fields.  This change will at least fix that part (even if people are creating a mess and adding duplicate fields).... as a company Jira admin, we can fix people's mistakes after this too ("Oh, these peeps made their own ID field that we already have?"  Delete, Replace, woohoo!).

As with many things in Jira Cloud, I wonder if this is a scoping issue for the design.  Perhaps there should have been a setting at the global level and at the team-managed project level for "Custom Field Visibility", with scope values of: project, global, or inherit from global setting.

@Simon and @Colomer - I hear what you are saying that, as it stands, "team managed" projects are unscalable because the custom fields are a dumpster fire. I would agree with that. However I where we disagree is that I am not confident "team managed projects" can scale. Again, just thinking about custom fields (and putting aside the technical ramifications of all those new instance-wide custom fields)...do we really think users won't create multiple custom fields with the same name just because another one is there?

The naming of team-managed custom fields is a tremendous (and I would say, fairly predictable) problem, and needs fixing ASAP. However breaking one of the core design tenants of "team managed" projects doesn't seem like an effective solution in and of itself, and carries a high risk for the rest of the product. From my perspective, something like JSWCLOUD-18756 (or, even more shameless plug, the solution I outlined in the comments) would be safer.

This is the versatility we all are expecting from this Agile tool. Hope to see this feature working soon

I can only agree with Simon. This feature is really interesting for our company as well, as all our projects are 'team managed'. Adding the same field over and over at each project, and not being able to use it for automations, dashboards, ... is really non-sustainable.

I would definitely suggest that the creation of this "company-wide" fields be managed only at an admin level, while project specific fields can be still defined by each project admin.

@Haddon - the reason this is so important is for medium-to-large instances. While it may look like it's separate now, it isn't. Try setting an automation on any commonly needed custom field, in a large instance it falls down because there may be 10s to 100s (or more depending on how large you are) of the EXACT SAME FIELD name. 

Further, big companies more and more integrate Jira data outside of Jira. As soon as you use the API, it also 'sees' both 'team and company managed' project fields without being able to differentiate. 

The screw up is already much bigger than many realise from what I can tell, to the point it needs a fix before a medium - big company can allow team managed projects. 

What's needed in a large enterprise is a solution that allows flexibility at the team level but also an ability to link teams to others, and this requires some sort of data consistency. Project level custom fields for example. 

Besides, why keep making people solve solved problems over and over again, just let them search what already exists first then decide if they need to make something new. 

Give an option to stop allowing duplicate field names while you're at it please Atlassian. It's a nightmare. 

As an admin of a medium-to-large Cloud instance containing both "team-managed" and "company-managed" I would ask that you maybe do not do this. In theory, it sounds great...but so do "team-managed" projects. In practice, this is going to get very messy, very quickly. Conversely, the workaround ("use company managed projects") may be heavy-handed, but it has the upside of not ruining the instance for everyone.

Not to sound like a cynical pessimistic jerk, but I am not at all confident in Atlassian's ability to not screw this up worse than it already is. 

As the team works on this, please pause to consider how this will impact "custom field sprawl" across a Jira site and how that can be effectively managed in the UX and for JQL filters, dashboards, issue import/export, bulk change, automation rules, etc. 

Please do not make the "fix" worse than the current un-shared field situation...which is at least understandable.

Thanks!

Hi All ,

I just left a comment on a bug related to this issue https://jira.atlassian.com/browse/JRACLOUD-76867  , i'm asking here to the watchers to do the same, comment and ask for priority if this is something that is impacting your daily work as impact our's . Thanks

+1

+1 for this.

+1

I so Exited to discover this huge custom fields BUG in NG projects and its business impact, which so long time did not solved by Atlassian Team. What should be happen that this bug will be fixed? I can't see NG custom fields in regular custom field managing tool and there is no option to share NG field between NG and classic project. It's unbelievable, that still any workaround did not provided to so many businesses and companies!

PLEASE CHANGE TYPE FROM SUGGESTION TO BUG

For us, as some people use team-managed (next-gen) projects and some use older projects which rely on the global custom fields, we need to be able to ensure that some fields can leap that fence, so our data alignment between both types of projects is correct.

My example would be you want all your staff to fill in release notes on their stories. Okay, so we create a "Release Notes" field which – irrespective of type of project – is added to all appropriate issue types, and now all the staff can add release notes.

This is particularly useful when you want to pull the release notes for all issues closed in a time period, a release, what have you.  It means one global field can now be used across all types of projects to store and retrieve this type of 'global' data.

+1 for this.

I have a couple of team-managed projects that work together (one is a service desk).  The service desk will create linked tickets on the kanban board.   There are some categorizations for these tickets that have to be separate custom fields on each board.  So for each, I am independently maintaining 2 drop down fields.  They do not filter together and can not be used on a dashboard together.

Yes please!

I agree. We need this feature in order to have integrations work. 

+1

On the bright side of this making life ridiculous, the filters don't work at all anyway. Perhaps they should get those working. Just a thought.

+5000000 (having to do this is idiotic)

+1 mission critical

+1

+1 - we really need this in order to integrate Jira with some of our other internal tools

+1

+1

+1 This is mission critical to our change management goals

+1

In addition to the query issue caused by not sharing common fields, moving issues from one project to another is causing us to lose values for these custom fields.  Having a shared custom "global" field would solve both of these issues.

I was surprised this didn't exist for Next Gen projects as it is such a common use-case for fields. Maybe Next Gen wasn't thought out that well?

It makes using Filters hard, as you have to have a similar field with a similar (but not the same) name so you can select the correct one in a filter for a specific project. E.g., if I have a field called "Development Estimate (hrs)" for one project, I have to call it "Development Estimate (h)" for the other project so I know which one to pick in filters for the first project. This is truly ridiculous.

+1

++1

+1

+1

+1

+1! 

+1

+1

+100500

This would be huge. Please add this feature. Its wild to me how this is not included in next gen