Next-Gen Project Issue With Custom Fields Across Multiple Projects

[Joe G]

I've created a few custom fields in my Next-Gen projects that are the same across projects, yet when doing Issue Filters, the same field can have unique ID's per each next gen project. Is there a way to use the same custom field (Ex. I have a dropdown called "department") across multiple next gen projects?   

[Carl DiClementi]

This feature is not yet available. 

@Joe G @John Tolle @Dave Macolino, and anyone else looking for this feature, I very much so agree that this is an important feature.

I've put in a feature request which you can vote for and comment on to help bring attention to the topic: https://jira.atlassian.com/browse/JRACLOUD-71712

[John Tolle]

Voted, although once I learned more about NG projects, I gave up on them completely and quickly fled back to classic projects.  I was sad because I was hoping that NG meant not just "next gen" but also "new and improved, with all the features of classic in a better, more streamlined format", etc.

It really should be called something other than Next-Gen so it's more obvious what it is.  Perhaps something like a Basic/Simple/Isolated/etc. Project.

[Adam T. Kowal]

I wish I could read the full list of features that weren't carried into Next Gen.  It'd really help me advise colleagues when they ask about NG.  For now - I can't recommend it because there are too many basic blockers.

[Jack Brickey]

Unless something has changed, which I doubt, this cannot be done. One of the fundamental characteristics of NG projects is that they are unique and nothing you do to one project will have any impact on any other project (NG or Classic). For this characteristic to remain true then nothing is shared.

[Dayong Wang]

To prepare certain reports, a shared custom field is needed not only across next-gen but between next-gen and classic projects. I was aware that https://jira.atlassian.com/browse/JRACLOUD-71712 is still in interest gathering phase, far to be implemented. 

[Jack Brickey]

I certainly understand the interest but TBH I disagree with the idea of allowing custom fields across NG projects. I say this based on the fundamental premise that NG is built on. That is, NG is supposed to be a singular project that does not require a system admin to manage. It is to be self contained so that a change in a config in the project doesn’t impact any other project.

of course that is solely my opinion and may not reflect what Atlassian ultimately implements.

[Tom Stratton]

If a custom field is of the same type and with the same name across projects why would we not allow that to be aggregated? It is very frustrating (a common complaint from me right now)

[Robby Ibrahim]

Because the premise of an admin-less config in NG means a standard user can make edits as they please to custom fields. Therefore, the aggregation would become meaningless and difficult for the aggregator to keep track of.

[Tom Stratton]

If the custom field is the same type and has the same name - this is not difficult to keep track of at all.

If a user changes the name of the field then it is no longer part of the aggregation.

[Richard Vencu]

If there are classic projects custom fields with same name as NG projects custom fields then automation is throwing error.

[Alexander Connell]

A good example of this is for a Customer dropdown list. In our company we have boards for Implementation, Support, Account Management etc etc. A Company does not work in a Silo'd way... most companies are trying to get away from that

[Scott Theus]

All,

There have been a number of changes to Next-gen projects since this post was made nearly a year ago, with more in progress. For more information please see the tickets below:

https://jira.atlassian.com/browse/JSWCLOUD-17266

https://jira.atlassian.com/browse/JSWCLOUD-18544

https://jira.atlassian.com/browse/JSWCLOUD-17392

-Scott

[John Tolle]

I agree with Dave in that this seems like a major oversight.  We are a small company (really small) and yet the only reason we use Jira is because of how manageable it is and the fact that so much can be reused across projects.  Anyone who doesn't want any "administration" isn't going to use Jira in the first place.

Did any of you create a ticket for this "feature request" yet?  If so, I'd like to add my vote.  If not, I suppose I'll need to create one.

[Peter Prijs]

Hi All,

Just out of curiosity, has this request been created?

I'm bumping into the same issues.

What I have noticed is that the same field can be created in duplicate.

However then the eazyBi starts breaking...

BR Peter

[Dave Macolino]

Shocking to see that this is the case. This really makes no sense. One of the advantages of Classic JIRA was the fact that it allowed global custom fields. 

I would love to understand the logic and reasoning as to why this wasn't included.  

One step forward, three steps back in my opinion. 

[Jack Brickey]

from what i have seen NG is intended to appeal to a no-admin-needed-environment. the more customization you allow the more you will need someone to admin it. I still stick w/ Classic as it meets my needs better at this point.

[Scott Theus]

Hi @Joe G,

Next-Gen projects don't use custom fields globally across projects like classic projects, that is why you don't see a "field scheme." So, currently there is no way to create a custom field in one project and use it in another. 

It's a big difference from classic projects, so I understand it can be frustrating. If you'd like to ask Atlassian to add it you can do so at https://support.atlassian.com/contact/#/.

-Scott

[Joe G]

That was my next question. if this was something on their road-map to include. I may want to revert back to classic projects as this current inability adversely affects reporting unless I compensate for the unique ID in each project. I could live with it for now if I knew it was coming.