Moving issues between projects in service desk

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. 

3 answers

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.

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.

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. 

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Feb 15, 2018 in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

1,143 views 6 19
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot