This wasn't a problem for a while as we just stopped allowing the creation of Team-managed projects in our instance. Team-managed projects are an administrative nightmare. Especially within larger instances. However, we have adopted Jira Product Discovery, which is built on the Team-managed project platform... Now the issue of having many duplicated fields is back and worse than ever. Especially within automation rules. There is literally no way to determine which field is associated to which project. You can use the "advanced" section and write out the json, but 1. that's definitely not as efficient and 2. then the field is identified by it's Id only (which makes the automation less human readable). Point is, there shouldn't need to be workarounds for this. Address the issue at it's core. Fields should be defined at the instance level, not granularly within projects. If you want to have a field using a name that already exists you either have a separate context in that field for your project or the field name has to be suffixed with the project key to distinguish it.

Please reconsider implementing this solution. Since our move to Jira cloud and allowing our users to create team-managed projects this has become more of an issue.

Thank you.

684cb16ed833: Are you saying breaking automation is not a bug – i.e., this feature is intended to break automation? Or are you saying that this IS a bug, but you are unconcerned that this breaks automation?

It seems surprising that this "isn't being considered" when it breaks the user experience as well as the automation. I've had to figure out which of the multiple fields with the same names I should be using for dashboard gadgets as it's impossible to tell the custom field from the original. 

I encountered this problem where a JSM project administrator enabled the "Incident management" feature of their project which caused a Severity custom field to be created, which duplicated an existing Severity custom field we were already using. This caused automation rules to begin failing due to duplicate fields with the same name. I have provided additional details in this support issue: https://support.atlassian.com/requests/PCS-175676

Within that issue I provided the following feedback:

1. Features are something that can be toggled by JSM project admins and creating custom fields is something that can only be done by Jira admins. It should not be possible for a JSM project admin to do something within their project that would create a custom field to be created. Creating custom fields is not something project admins should be able to do, either directly or indirectly.

1. Users should be at least warned that their actions will create a custom field, especially if another field with the same name already exists. I’d expect that users should actually be prevented from creating these fields if an existing field with the same name exists, which has the potential to break things, as it has for us in this case.

1. Why is it even possible to have 2 fields with the same name? If it can cause problems to have 2 fields with the same name, this shouldn’t be allowed.

1. A process should be created to handle this situation more gracefully. Perhaps if the field exists, it should present the admin with a wizard with options to make use of the exist field, perhaps modifying it, or to create a new field, an option to migrate existing values, and remove the existing. Or perhaps more generally when enabling this feature, the Jira admin can choose which existing fields to use or what name to use when creating a new field. The way this works currently is poorly designed.

+1

Sadly, each time Atlassian introduces new functionality, it "breaks" the base product.

Hi, same scenario (and solution) I would expect for issue types, do you have another ticket to track this? thanks in advance!

This is really annoying, and causing long investigations to understand what, who and how!

We had this issue too in our company. We had an incident because a user created a custom field in her next gen project with the same name of an existing custom field. Therefore, filters, dashboard, etc that used the original custom field were broken. Moreover, (as explained in the ticket with Atlassian - PCS-34104) - We Jira admins do no have enough tools to reach in which next gen that 2nd field was created (we don't have that info in Jira logs). Fortunately we were able to contact the user, and she told which was the next gen project. We then remove this 2nd field on it and our incident was solved. Too much work / depending on reaching the user and her memory!!!

I’m trying to share something as simple as a follow up date and follow up notes. This is definitely impacting our ability to use the next-gen projects. Also, issue types created in other next-gen projects should also be available to be shared. The biggest issue too with duplicate fields such as dates is that calendars can only display one date field type at a time. There are a ton of ripples that are limiting our uses so much so we may have to stop using these project types till more advancements are made.

Don’t get me started on the fact that I cannot create sub-task issue types