Moving issues between projects in service desk

[Ross Gardner]

I'm just trying out service desk and think it looks excellent.  However our use of JIRA so far has been for a development team on an Agile project and therefore our project is setup for stories, epics, etc..

We want to extend the use of JIRA through service desk so that all IT related requests can come into one key location.  Adding the service desk to our development project doesn't seem to be the way to go as the customer gets presented with all the terminology from the agile project.  A new service desk project provides the customer user experience I am after.

Often the issues reported have nothing to do with the development team and can be fielded easily by support. Service desk excels in this scenario.  Occasionally however an issue needs to be passed to a developer or needs to result in a new user story in the development project and I can't find the correct workflow.

Using the "move issue" action to move it into our development project seems to completely remove it from the service desk and the user who raised it has no visibility as it is within the development project that has no service desk enabled.

The only alternative we can find is to close the service desk issue and raise a new ticket in our development project which doesn't seem correct.

Does anyone have any experience with this.  I don't want a service desk on our development project as the backlog is constantly groomed to ensure that it is relevant and the thought of outside users dumping requests in it sends me cold. 

[MikeyS]

There are ways that you could give customers (i.e. anonymous users) visibility into your development project so that they wouldn't lose sight of their issue, but it would still remove the issue from the Service Desk interface, so I don't really recommend going that route.

Instead I'd look into creating a new issue in your development project and linking it to the Service Desk ticket.  If you're on a server version of JIRA then you could use JMWE, Script Runner, Exocet or some other plugins to build in automation surrounding the creation of the development issue and updates between the two issues.  If you're on Cloud, then you're probably left manually maintaining both issues.

One other option would be for you to make your developers agents in your Service Desk.  As Service Desk is now a pay-per-agent arrangement, there is some expense associated with this option, depending on how many developers you have.  This should (although I've never tried it) allow you to directly include certain Service Desk issues directly on their agile boards.  You would do this by somehow marking Service Desk issues for development, and then modify your board filters to include these marked issues.

[Daniel Smith]

Essentially Atlassian has set this up to be obtuse and necessitate paid access everywhere. 

If you move the issue from service desk to JIRA proper, if the portal requester has a service desk account (non-agent), they essentially lose the issue as they don't have permissions to JIRA proper. 

Okay, so if you simply create a new JIRA issue and link it to the original service desk issue, unless the dev is a service desk agent he cannot see the service desk issue except that it's been linked...the dev cannot view the service desk issue at all.

So you're buying another license, either for the portal requester for a full JIRA license or to add the dev as an agent. If not, whatever else you do will be inelegant and inefficient and will negate the point of the service desk nearly completely as it functions nearly as a totally separate app. 

Why wouldn't we just get Aha! or another product if there is no material advantage to the service desk besides familiarity with the JIRA UI and configuration? With the others, the users on a non-JIRA license can actually track and comment on issues going through development. 

[Steve Larsen]

2nd this request. SD should be the wide part of the funnel, allow agents to read requests, ask questions, then shift them over into development or other projects where they are managed as tasks or Agile stories.

Eventually the issue is closed from a development PoV and the issue gets marked Done.  The method suggested below requires a lot of maintenance for the agents.

[Deleted user]

I know this is a very old thread, but to possibly save me the time of continuing to search for information about this, Steve my desired use case is exactly the same. Has anything changed since 2016??

[Mike Gardner]

It's now May 2021, anything changed to support this common use case?

[Hassan Wamalwa]

You could try Exalate by iDalko. Been working of us in terms of syncing issues/comments/feedback between projects.