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

+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!

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

The only thing preventing us from using Next-gen projects is the proliferation of duplicate custom fields. ALL these duplicates are displayed when searching, even if only one project is selected. If only the fields available for the selected project are displayed, we could move forward with adoption. I hope this will be solved so we may use Next-gen projects.

I'm probably in the minority, but I like the vision for Next Gen projects.

However, this feature really is critical for Enterprise level use.

Do you have a projected timeline, like which quarter this year?

For a cross-project report, a shared field is required. Before I had a workaround solution using batch edit. Today the way is blocked! I assume it is due to recent updates in Jira??

Hi rrobillard re: "You have to know at the time of creation which other project you want to be like, and it's an all or nothing. After that, you wouldn't be able to share any new fields." That's assuming we implementing it that way, which to date is not the plan.

We are currently thinking about this more as a form of inheritance, as opposed to something only at creation time.

Regards,
Nate

Templating seems like the worse option. You have to know at the time of creation which other project you want to be like, and its an all or nothing. After that, you wouldn't be able to share any new fields. 

We routinely tweak our processes so any new fields created after the project creation likely couldn't be shared. We also don't want 100% standardization across projects, just sharing some best practices while allowing flexibility. Templates just don't seem like they accommodate these needs.

We have very few projects that work in isolation, so next-gen continues to be a no-go for us, which is unfortunate since that is where all your development time is being spent. 

-Rachel

Hi Guys,

Let me give an update on this.

We know that you guys need shared configuration and there is a few ways we could give it to you.

1. We could provide a global field that could be surfaced in Next-gen.
2. The better option is to provide the ability to template and share configuration across Next-gen projects. This is the better solution and the solution that we are working towards.

"Working towards" I am sure is frustrating to hear for each of you that have commented on this ticket. We know that sharable configuration is an important part of Jira and something you all need. We are doing the research into that now, but it is a fairly large body of work. Also there are some features like Workflows that need to come first, because they are more highly voted and importantly so we can correctly design the templating experience (backend). I just wanted to shed some light on what is going on and let you know that we are not ignoring you, in fact we are doing the exact opposite and working towards that goal.

Warm regards,
Nate

Folks, for smaller businesses, this feature is critical for not needing a dedicated role of Jira Administrator.

The NG projects are great for being simple to configure. This request is literally the next step to make them useful for typical operations of an organization that rely on reporting across projects!

Thanks,

Dave

We need our custom fields to be deployed across all projects for reporting

+1 - crucial for filtering and ETL

+1 - For this feature, its essential for our organization. Please add for NextGen! 

Anyway to bump priority on this? We may be forced to use abandon next-gen and go back to Jira classic as this affects our ability to report on status across boards that span our department.

Based on the [public roadmap|https://www.atlassian.com/software/jira/whats-new/next-gen], it looks like Atlassian is planning this feature (or at least a workaround for it) for 2020. I believe with these two features, we'll all get what we're looking for:

1. "Share next-gen project configurations and workflows" sounds like a copy-paste of a project config where you'd get the same custom fields, although they wouldn't really be the same when searching across projects
2. "Improving JQL search across next-gen projects" which probably means searching across those different-but-same custom fields

It's too bad

+1 - For this feature, its essential for our organization. Please add for NextGen!  

Cross team support for shared custom fields (and shared epics) is very needed.  I'm trying to convince usage across other teams, but without this feature it's tough to have a solution for the needs within the department.

I made an earlier comment in support of this feature. In the time since then, no response or action was taken. My team is moving all our projects off NextGen for this reason. Nice try Atalassian, but an aim and a miss overall for NextGen.

+1 for this feature. It's really important

+1 for this feature. Makes the transition to next-gen projects impossible right now.

This feature is crucial for our work optimization and frankly I am surprised this isn't already available. +1 for this!

+1 for this feature. Needed for our daily work!

We are moving to all NextGen projects, and this is blocking our work. Would really like to see this functionality.

Deal-breaker for us as well. We migrated our projects back to classic. We shuffle tickets between projects regularly, and need to track tickets consistently between projects for releases and other reporting needs. 

Like most others, I have a Jira instance with a mix of classic and next-gen projects. The classic projects all use the same set of custom-fields (like normal), and a number of important business functions/logic have been tied to some of these (think compliance). Recently a next-gen project admin added a field to their project and named it exactly the same as an existing field, because she couldn't find the canonical custom-field. (Why Jira allows duplicate field names is pure insanity, in my opinion.) So now my Jira instance has two fields with the same name, which breaks all JQL reports/subscriptions that reference that field by name, which is all of them (the name is now ambiguous).

It seems that when a custom-field is added within a next-gen project, Jira adds it to the global list of custom-fields (you can see this in the autocomplete in Advanced Search), but that field doesn't appear on the global configuration page for Custom Fields. This is typical Jira strangeness and makes no sense.

Allowing custom-fields to be added to next-gen projects would solve my problem immediately.

It would also be helpful if you could clone issues and have it create the custom fields on the Next Gen project you are importing it to. 

Our organization really relies on the custom fields and I would consider this a complete and total blocker to us being able to fully adopt next gen projects. Some of the features seem great, but it has some major gaps - this being one of them. 

Have had to re- migrate all our projects back to old style projects. This seems such an obvious thing that is needed

This is a showstopper for us in using NG projects - we have setup sync and reporting through API across dozens of projects and having to update the reporting tool every time there is new project in Jira is bad practice.