Summary

If there are multiple fields in a Jira instance with the same name, it can cause conflicts and/or confusion.   Multiple fields with the same names won't always cause conflicts, since most of the references to these fields in Jira use the field's unique ID and not its name, but it's a good idea to keep field names unique too, to avoid the occasional conflict as well as making things easier to use.

Environment

Jira Server & Datacenter

Diagnosis

The easiest way to see if you have any duplicate field names is to look in the Jira interface:

⚙️ (Jira Administration)  > Issues > Custom Fields

In the example screenshot below, there are four different fields called 'Team':

It is also possible to search in the database, if necessary, for fields with the name in question, like the below query that will find the 'Team' fields from the above image:

SELECT * FROM customfield WHERE cfname = 'Team';

 The above query searches for fields named 'Team'.  To search for another name, replace the word Team inside the single quotes.    This query is formatted for Postgres and may need to be edited for use in other databases.

Cause

It is currently possible to create multiple fields with the same name.  There is a Suggestion to disallow the creation of duplicate custom fields logged but in current versions, Duplicated names of Custom Fields are allowed.

This often occurs when a new plugin installation adds a field with a name that is already in use.  This situation is often unforeseen, and can lead to conflicts.

Solution

 In general, it is possible to work with multiple fields with the same names.  On of the main problems the situation can cause that is not easily resolvable is that JQL queries saved as filters usually refer to fields by their names and are stored in the database as plain text.  If more than one field exists with the stored name, this can cause unexpected behavior or errors with filters and other JQL.  The article Managing custom fields in Jira effectively covers how to find saved JQL filters that refer to any given field. If affected by this type of conflict, it is recommended that one of the conflicting fields be renamed and any affected filters be manually corrected to account for name changes if needed.
 If one of the conflicting fields is a Managed Field, it should be kept and other conflicting fields should be renamed or removed.  Unlocking or editing a Managed Field is not recommended or supported.

There is no single process for resolving conflicts like these.  It is up to the Jira Admin to decide what the best solution is.  The following is a process that can be followed to help choose a solution:

1. Identify all conflicting fields.
2. Select any completely disused custom fields for deletion by Analyzing the usage of custom fields.
   1. Delete the disused fields following guidelines at Editing or deleting custom fields.
3. Choose one remaining field to keep as it is:
   1. If one of the fields is a managed field, that one should be kept and not removed or altered.
   2. If both conflicting fields are unmanaged and in use, it will be up to the Jira Admin to select one of the fields to be renamed.
4. Check & mitigate the impact of the rename:
   1. For information on the impact, refer to Managing custom fields in Jira effectively.
      1. Most of gauging the impact means managing user confusion; Jira itself usually refers to custom fields by ID, not by name, so a rename will not break most functionality.
   2.  One known impact of renaming a field is that because JQL filters do not use IDs, they will not be updated when renaming and will need to be updated manually.  To see which JQL filters are referencing the field by name, use a query like the one below:

   3. SELECT * FROM searchrequest WHERE reqcontent LIKE '%Team%';

       The above query should be edited to include the field's name in place of the example field's name, Team, inside the %s.   This query is formatted for Postgres and may need to be edited for use in other databases.

   4. Edit filters as needed to ensure they will work with the field's new name.
5. Rename any fields select for renaming.