Hi,

We have released a bugfix to target the 3 top most impacted fields (Impact, Root Cause and Severity). If you are experiencing duplicate field problems with any of those three fields, delete the copy of the custom field that we are creating on behalf of you (NOT the one you've created yourself) and we will never re-create the field again.

If anyone else is being impacted by fields other than Impact, Root Cause and Severity, please vote on these other tickets instead:
https://jira.atlassian.com/browse/JSDCLOUD-13035 for:

• Change Type
• Change Risk
• Change Reason
• Implementation Plan
• Backout Plan
• Test Plan
• Change Start Date
• Change Completion Date
• Planned Start Date
• Planned End Date

https://jira.atlassian.com/browse/JSDCLOUD-13036 for:

• Affected Hardware
• Severity
• Pending Reason
• Source
• Product Categorization
• Operational Categorization
• Responders
• Affected Services
• Urgency
• Approver Groups

If you are experiencing problems with duplicate fields breaking automation, please vote on this ticket instead https://jira.atlassian.com/browse/AUTO-161. This is a known issue with Jira fields in general, not just JSM

We're closing this current ticket off for now as this ticket isn't representative of a single bug, but a collection of them. Your votes on the new tickets should help us address the problems more urgently.

Thanks all for your patience,
Albert

This happens for us with most of the change management fields. At one point, we had five identical "Change type" fields. This duplication causes our Automations to fail because they don't know which field to use. The suggestions support gave me didn't fix the problem.

This started happening for us in JSM with the Urgency field. I can't say for sure but it seemed that after deleting the duplicate Urgency field, it didn't come back until I loaded the Jira Automation page for a JSM Project. 

This occurred in our instance on 2 occasions now in May. The first time is when creating a new JSM project (with shared config of an existing project) was created, Jira created 2 duplicate fields that already exist, Impact and Urgency fields. The result was that all priority automation rules using impact and urgency started to fail across all JSM projects in the instance, the error was "duplicate fields with different values", once the new duplicate fields were deleted this solved the automation failures.

The second occasion wasn't on project creation it was when I created a new request type in an existing project, the symptom again was the automation rules that started failing, in the audit log, during the same time or moment before i created the request type , Jira created impact and urgency fields under my name as per the audit log.  

The details can be viewed on the following support ticket: https://support.atlassian.com/requests/JST-879818 , the workaround has already been implemented by support. Hope this insights help.

I've encountered this problem with the Severity field being created when a JSM project administrator toggles the "incident management" feature of their project which causes a Severity custom field to be created. Like with Andreas, this caused a duplicate Severity field which broke existing Automation rules. You can find additional details in the support ticket https://support.atlassian.com/requests/PCS-175676

I provided the following feedback in the support ticket which is relevant here:

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.
2. 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.
3. 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.
4. 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.

Thank you both ad92d87fa335 & andreas.link for getting back to me.

At this point in time any information around reproduction and circumstances that it occurs or re-occurs will all be helpful for us to narrow it down. We will take your comments as leads and see what we can find from here.

Keep in touch!
Albert

Hej Albert,

I had opened a ticket (https://support.atlassian.com/requests/JST-859650/) some days ago and was pointed to this issue by the supporter. I had very precisely (incl. screenshots) described a way to reproduce this field creation issue.

In my case the "Severity" field is always duplicated, which - as a consequence - then leads to automation rules responsible for measuring on SLAs to fail due to fields with the same name, which then as a consequence creates quite some trouble if we are not able to follow our SLA agreements - just due to an automation rule "randomly" being skipped.

Let me know, if I can support you in reproducing it.

Hey Albert, we're pretty badly affected by this bug time and time again on our instance. The thing is that we've also seen this with the Urgency field, and in the audit log it'll show the "duplicate" field as having been created by a user outside of the context of creating a new project. The user in question doesn't even have the necessary permissions to create custom fields.

The issue has even gone as far as having the user supposedly create a custom field (again, without the permissions to do so) that is not even a known type of Custom Field.

(says field is LOCKED by Jira or another plugin, custom field type "Unknown" and default value in context is "Unsupported", so baffling in 3 ways).

Hi everyone,

I'm Albert Wang, an Engineering manager from Jira Service Management.
We’re working hard to identify the root cause of the field duplication problem of JSM created custom fields. Unfortunately, it is proving to be quite difficult to track down. We'll be taking steps to help isolate and resolve the problem & we'll keep you all updated as we discover more.

Thank you for your patience as we continue to work on this issue.

Albert

Investigation already done:

• https://getsupport.atlassian.com/browse/JST-685660
• https://atlassian.slack.com/archives/CFJ8DQZT8/p1635123780013600