nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Default custom fields & custom issues types that come with JSM out-of-the-box

Darrel Jackson

I am a Jira admin for our Jira Premum cloud instance that also has JSM. I personally don't use JSM. Only one team in our organisation does and they use it as a simple "front door" rather than a full blown ITIL solution.

I'm trying to reduce the number of custom fields and customer issue types in Jira however some of them look like they might come from JSM.

Is there an admin guide or reference that lists all the custom fields and custom issue types that come out of the box? I'm keen to delete a bunch like "Change type" and "Change risk" but I don't know if they were created by/for JSM.

For custom fields I see ones tagged with a description "Created by JIRA Service Desk.". But I don't know if they would break JSM if removed or if they were recoverable in the event we needed them in the future.

Help would be appreciated.

Accepted answers

Joseph Chung Yin

@Darrel Jackson -

To supplement what @Brant Schroeder suggested, if you access the system "Settings" >> Issues >> Custom fields, you will see all the JSM out of the box fields are flagged with "LOCKED" symbol. You can search for the key word "Service", you should get all the JSM default fields -

You should see the fields with the flag. Example - a few fields for your reference

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

All comments

Brant Schroeder

@Darrel Jackson The custom fields and issue types that were created by JSM should be easily identifiable by going to the JSM project and seeing if they are included in the issue type scheme and field configuration. You can also see what projects are using a custom field by looking at the screens and context on the custom field. I would suggest working with the team that is using JSM to ensure that you do not delete something that is being used. SLAs in JSM are also custom fields so you do not want to delete those. They should be locked and a type SLA custom field. There should also be locked satisfaction custom fields. Most of the custom fields generated by JSM on project create have a good description. With custom fields when in doubt leave it and investigate. Once you delete it, it is gone and that can be a real problem if you loose a bunch of data.

Joseph Chung Yin

@Darrel Jackson -

You should see the fields with the flag. Example - a few fields for your reference

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

Darrel Jackson

Great, thank you. I think that was what I was looking for: confirmation that the JSM out-of-the-box ones are marked as LOCKED so I can safely delete other custom fields.

Brant Schroeder

Correct

Joseph Chung Yin

@Darrel Jackson -

As we suggested - before you delete the custom fields, you should work with each project content owner to determine if they are needed. You can always hide the field(s) first, and then delete them once the proper analysis is completed.

In Jira/JSM, once an object (i.e. fields) is deleted, it is gone and cannot be restored.

Best, Joseph

Darrel Jackson

What I've opted to do is do a JQL search for each custom field to ensure there are no issues where the field IS NOT EMPTY. Then I've moved the custom field to the trash so if it does turn out to be needed the team have 60 days to say so. I've only done ones where there are no screens assigned. Thanks for your help. This has trimmed our custom fields from ~160 to ~140.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management