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

@Carol Low

Following the implementation, there is currently no way to easily distinguish company-managed shared custom fields, from system fields.

Once a company-managed shared custom field has been added to an issue type, hovering over it's name will generate the same message as system fields: "Jira created this field. You can't[...]".

Shared custom fields should not be treated visually the same as a system fields. The message is inaccurate. Jira did NOT create those shared custom fields, a product admin did. Can Atlassian please fix that?

Thx

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

+100500

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

+1

+100 PLEASE Get this fixed. This is really a big issue. 

+1

+1

+1

+1

This is currently a show stopper for us, too. I found this issue because we need to be able to copy fields between a regular and nextgen project, and I cannot get it to work across the project. If the same custom fields were allowed, it may actually work.

This is a show stopper for us. Very disappointing that Next Gen projects would be released without even this basic minimum requirement being met. 

+1

+1 on this. I manage a number of different projects and it would be great to not need to duplicate these efforts and possibly introduce typos that could negatively impact our search filters.

Need this as well, aggregation has to be done manually because fields that represent common metadata across projects are seen as unique and there is no method to aggregate them unless they are considered as the same field across next-gen and classic project types.  We can work around this for now, but now we have introduced the possibility of human error into our reporting processing.

+1 on this one. We need to have a common custom field for all development projects and it would be great to not have to define it each time.

+1 on this one... it's very annoying trying to use tags that don't work between my service desk and Jira software

We're having a field of same type and same name in two next gen projects. Moving issues between the projects still loses the field value even when `retain` is selected. Losing data w/out warning when moving between next gen even when `retain` is active is a show stopper

nsturgess, As of now, when I have a field in 2 project with the same name it is just aggregated on a List View. But when I use a field of label type the results display one column but the values takes two rows - are stacked vertically. If I would have 10 project then each displayed item in a list view takes 10 rows.  When you said "So no more repeating fields in search dropdowns or in search result columns", did you mean fixing that or something else?

Yes, can we have a custom field that can be used across more than one project please

this is a very annoying issue - even when the setup of the issues in two different projects is identical you can't move an issue between projects without losing the custom fields. Even allowing for a simple mapping during a move would improve the situation.

+1 from me for a way to use a custom field in more than one Project - it could even be keyed by the name!

Maurica there's and workaround for this problem. They added the possibility of creating your own user roles and... a few days ago I've noticed that we can restrict the visibility of task for the specific role.

So my idea is:

1. one big project
2. epics - subprojects - visible for specific user roles
3. tasks/subtasks - difficult but possible managing of visibility and accessibility....

Plus

--all my subprojects have same custom fields - it's reportable better than now

Minus:

– I have plenty of work with security and managing users 

– there's no way to make specific new kind of epic task like "subproject"

PS. Dear Jira Team, do we have any progress in finding a solution?

im new to jira, and trying integrate my team workflow into next-gen projects, without shared custom fields its pointless to use next gen in teams with more than 1 project.

017df84e2765 Annoying I agree. That is why we are just about to rollout an update to Search where fields of the same name and type are aggregated. So no more repeating fields in search dropdowns or in search result columns.

Without this feature, I've concluded next-gen is only useful for completely siloed projects; where tickets originate and are completed only in that one project, and nothing will ever need to be reported on, searched, or in any way related to any other project. We only have a couple which are used for one-off, short term projects. 

Would love this feature (as I thought it already worked as such based on classic behaviour) - We've migrated all our sprint teams and product backlogs to next gen due to the ease of simplicity. As part of it, we standardized our issue fields, recreated them in each project, but when migrating work from the product backlog to sprint teams, we lose custom field data despite the naming being identical. It's overhead/prone to user error to constantly remember to reset these with their previous values post-move as they get lost.

Same problem, we don't want to migrate everything to next gen just to be able to use a custom field for all the company  (That would take months of work just for this issue)

Yes Steven Danneman, I am using exactly the same work around to report on a field we use for tracking the category of work done, and it's into excel to bring together all the columns that have this same name but are not actually the same field. Very bothersome. 

I also found that when I was querying to exclude subtasks that the field in classic Jira is Sub-tasks and in the next gen projects it is Subtask. It took a while to figure out why my next-gen query did not work as expected (Epic for example is named then same!)

Please Atlassian, make it possible to share fields, for new projects we are just going back to classic.

Yes! I'm on the Security Team. We need to assign bugs to all other product development teams. We want these tasks to be incorporated in their Project workflow, but we need to track and report on global fields like type of vulnerability, and security severity which is different from team priority.

The best we've come up with across our ~50 Next Gen projects is a shared issue type. Now I can query and report on the same issue type, but I have to view 50 different columns all named Type of Vulnerability, and it's back to Excel to get meaningful reporting.

This feature would keep me entirely within the Jira ecosystem.

Can anyone at Atlassian stop gathering feedback and just get this done?  It is obviously not helpful when we create a custom field that it can't be shared across other NG projects.

With the new Roadmap feature in the Next Gen projects seems great to use but not having the option to add the custom fields is major blocker unfortunately won't be able to use the Roadmap feature.

Please prioritize this as it would ease the adoption of Next Gen projects

100 times yes! Being able to share custom fields across Next Gen projects would be incredibly helpful for automation.

We use a "Customer" field in our Classic Jira projects which we use to track billable hours to our many customers. 

We have recently commenced utilising Next-Gen projects, but missing the ability to create a single custom field that propogates across all of these NG projects is creating a great deal of duplication and errors. 

Please address this

Hello everyone.

I strongly agree that this functionality is needed.

It seems crucial for managers who want to:

1. standardise teamwork
2. standardise project management
3. measure progress on whole team projects and tasks.

Now I have to switch to excel-girl and spend hours to prepare comparable data.

Hi 0f690b14ec1c, I couldn't agree more about duplicate fields issue, we are working on a fix now and it will be solved soon. Either way Global fields in Next-gen projects is also something we want to add to the roadmap. Just wanted to give you an update.

Regards,
Nate

I agree.  This is heavily needed especially when you start talking about using filters based on a common custom field.  You can't use the custom field as a column, you have to include all the different custom fields from the different projects for both the query and the result grid which is clunky.

If I could vote for this one a hundred times, I would.   All divisions of our company use Jira for some level of tasking, project management, and time keeping.    Lack of crossover or 'custom field' sharing in Next Gen really makes things difficult, since all divisions are typically working together for a common goal.

Same here. This is only compounded by the fact that you can't move issues from one next-gen project to another while retaining custom field contents.

Unless you go the clunky route of CSV export/import, which in my case fails with attachments among other things...

Same problem here

Same problem

Hi guys,

We are currently discussing this work's place in the roadmap, so I just wanted to call that out. When I have something more concrete I will give you guys an update. Thanks for your patience.

Thanks,
Nate

Agree with the above comments. Please have this ASAP

Same situation here, I agree with @shafayet hossain

This deficiency is absolutely mind boggling.  Please resolve ASAP!

Our team has been using next-gen projects now for a few months. The inability to create custom fields to span those projects severely limits what we can include in our cross-project reports.

Please add this tomorrow!

I completely agree with @shafayet hossain. We cannot use next gen projects because of this