What do you think: Should "Move Issue" to JSM project allow selection of "Request Type"?

Question

If so, vote here! ;)  ---> https://jira.atlassian.com/browse/JSDSERVER-12714

Hello,

I don't know about all of you, but I find myself and my team often moving tickets back and forth between two Jira Service Management projects, for a variety of reasons.

During this movement of tickets back and forth between projects, Jira's native "Move Issue" or Move Wizard tool asks to "Select destination project and issue type" right from the outset.

Could you imagine how much of a pain it would be if you could only select the destination project, and after the move, you had to then change the Issue Type from whatever default it had selected?

Well, that's the problem I'm facing when moving tickets to another Jira Service Management projects. More specifically, that's the problem I'm cleaning up after when my Jira colleagues move tickets to other JSM projects...

I'll find tickets here and there with the totally wrong "Request Form" and "Issue View" associated with them, because our Jira Service Agents who moved the tickets had forgotten to take the additional step of choosing an appropriate "Request Type" after the ticket has been moved to the new project.

On top of remembering to change the "Request Type" at all, a Jira user has to have some background knowledge or memory of which "Issue Type" the desired "Request Type" is associated with. If they had selected the wrong "Issue Type" in the move process, that introduces a secondary post-move step to set the "Request Type" appropriately!

I'm tired of the additional cleanups and reminders!

Do you move tickets back and forth to a Jira Service Management project? Would you find it helpful if the Move Wizard had a built-in selection for "Request Types" when the destination project you've selected is a Jira Service Management project?

If so, vote here! ;)  ---> https://jira.atlassian.com/browse/JSDSERVER-12714

Suzy Nicholson · Answer

@Curt Holley I agree! Believe it or not, we do try to limit moving tickets around!
(By the way, by back and forth, I don't mean one ticket going back and forth multiple times, I just mean, we move some tickets one way, and other tickets the other way. I was a bit hyperbolic, I suppose!)

As for why tickets get generated in the wrong place:
Some of it just generally comes down to "customer" (non-support staff in our company) confusion over which team(project) would support their issue or apathy over selecting the correct project/request type within the Jira Portal.
There is some overlap in what each team does such as licensing and installation of software vs development of tools and add-ons for the same software.
We've tried to mitigate this in a few ways such as confluence docs explaining the roles of each team, and listing examples of issues that would be handled by each team, and simplified names/descriptions of Requests on our Portal.

As for reasons why we move tickets around:
-Until recently, our JSM projects only had one project role other than Customer or Administrator which was "Service Desk Agent".
Our organization prefers that all team members get all updates on all tickets.
So, for example, the IT team members are set as the "Service Desk Agent"s on the "IT" JSM project and would get notifications for all issues in that project. But that same project role was used for the permissions such as "Assignable User" and "Service Project Agent" to reply to customer etc. 
(There's other reasons why why don't use "Logged in users" or "Product Access")
We're working on rolling out a new project role "Service Desk Agent - Lite notifications" that I can give all the same permissions to, minus the notifications.
This is taking care of at least some of the movement of tickets that aren't so necessary :)
-We find it important to the requests in the right project for project-specific filtering, issue count.

We are currently using Jira Cloud, so I'm hoping that it will be possible to get the feature implemented.... At some point!

Curt Holley · Answer

I certainly do not encourage the moving of JSM tickets, especially not back and forth!!

I would be looking into how to minimise such movements, as they are asking for trouble/confusion etc. That said, I do know what you mean and Yes! it would be handy to be able to select the request type as part of a move.

Suggestions for alternative options:

* If between different JSM projects, why not just leave the request where it is and add tasks or sub-tasks for the different teams/people to work from? Seeing they are all agents anyway. This could be automated and even send linked tasks out to the other project(s), as well as syncing transitions when and where appropriate.
* Similar to the above point, but tasks going out to Jira Software or Work Management projects. This means not everyone needs to be an Agent to contribute to the Request/Incident.
* If you have to move tickets between projects (but really, I do recommend challenging that notion) then do it via automation, where you can "Edit Request type" as part of a rule/set of rules.

Question @Suzy Nicholson are you using Cloud or Server/DC Jira? As that could compromise automation options and of course likelihood of the feature ever being deployed.