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; } } }

Best practices for decommissioning Request Types & Issue Types

David Quiram

I'm looking to solicit opinions from anyone who has been through this process before. Years into managing a JSM help desk and the team decides to decommission a specific Request Type and/or Issue Type as they are no longer supported or relevant, but they don't want to lose the potential data in those associated issues.

How have you managed this?

My first though was maybe just create an 'Archive' Issue/Request type to migrate the issues into, but wasn't sure if there were any better methods that the community follows.

Accepted answers

Tomislav Tobijas

Hi @David Quiram ,

If you're on Premium, can't you just use (newly released) issue archiving? I'm thinking this would be the best way to do so.

Not sure if in JSM projects "Archived issues" page is visible in the project navigation (looking at old/current UI), but once you finish archiving, you should be able to find all archived issues via https://<sitename>.atlassian.net/jira/servicedesk/projects/<PROJECT-KEY>/issues/archive

As for request types, you can maybe just hide it from portal 🤔 (not sure about that one).

As for completely deleting issue type, I think what we did a couple of times is to migrate all those issues to existing issue type + add some kind of label just so these items are later searchable.

Cheers,
Tobi

All comments

Tomislav Tobijas

Hi @David Quiram ,

If you're on Premium, can't you just use (newly released) issue archiving? I'm thinking this would be the best way to do so.

As for request types, you can maybe just hide it from portal 🤔 (not sure about that one).

As for completely deleting issue type, I think what we did a couple of times is to migrate all those issues to existing issue type + add some kind of label just so these items are later searchable.

Cheers,
Tobi

David Quiram

Issue Archiving might work, depending on a few other factors. I read that it removed the issue from the project. Does that mean stats for the project would be affected?

Like a stat of how many issues have been handled by that project. Would that include archived issues or would we need to change how that stat is gathered. Things like that. The documentation you linked is purely HOW TO and doesn't offer much in the way of contextual significance.

Based on what I can find for the datacenter version of the documentation, it will removes the issue from index, so would affect reports, dashboards, etc...

I would love to find actual documentation going into that for certain, but it's a sound assumption IMO.

We already hide the request types from the portal, but on the management side of things that's just messy and leaves old, unused elements lying around that just end up being clutter. Hence why we would like to just delete them. But if we delete them, would that impact the current, or archived, issues using them? I can only assume so, so we probably would need to migrate them to something else.

Tomislav Tobijas

Related to this:

Like a stat of how many issues have been handled by that project. Would that include archived issues or would we need to change how that stat is gathered.

I've just tested it and it seems that archiving an issue would affect the stats such as reports and dashboards (I've made a simple test of pie chart that represents statuses).

And the answer for this:

But if we delete them, would that impact the current, or archived, issues using them? I can only assume so, so we probably would need to migrate them to something else.

would be also yes. Although, when deleting req. type you're being asked/noted to (bulk) move all tickets assigned to that req. type to different one.

2025-01-08 22-17-25.png

When talking about indexing/reports I don't see much of a choice than to leave all those issues 'active' in a way that you would move them to a new/different issue type and potentially add a label or some other mark just to know these are migrated. This way, you could still use them in reports. Or, if you could export those reports and 'timestamp' them, maybe an option for archiving would still be on the table? 👀

Susan Waldrip

@Tomislav Tobijas , when using your "labels" approach, could you then use JQL in rules, filters, etc. to exclude any issues with an "archived" label? I know that's a hassle, but if you didn't want to see those issues or include them in query results, that might be a way to omit them. I don't have JSM Premium, but didn't the new archive issues feature account for that problem?

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