Multiple Service Desks/Projects

[Nicole]

I have a service desk which internal and external Customers/users can create tickets from, mainly from sending in emails to the SD.

I now want to create a project for each internal department, such as Admissions, Media, Finance etc and be able to move tickets into them, so that it aids management, tracking and reporting.

The Main Service Desk will be the one where all the tickets come into but the each ticket will be categorised and transferred to the relevant Service Desk for investigation and resolution.

How is the best way to to do this please?

Many thanks.

[Mike Rathwell]

Hi @Ann Farrant ,

I have almost exactly your scenario in my instance. In my case, I use it for times when, for example, a ticket is created in ITOps but belongs in the DevOps of Salesforce projects. What I did:

• Created a custom field with radio buttons to select where it was going and put it in a simple screen to be used for transition.
• Using either "Create on Transition" or "Jira Misc Workflow Extensions" (both are great for this), created a "Hand-off" transition that uses that hand-off field in the transition screen.
• The post-function for "Hand-off" conditionally creates an issue based on the value set in the hand-off field, copies across summary with "Handed off from X project" appended, the description, and allows for a comment
• Create a link between the original and the newly created issue.
• The transition takes the original to a "done" state

[Nicole]

Hi Mike

This is really helpful. So to clarify, you have multiple service desks/projects and they are configured as above to aid handing over and management of tickets?

Does this allow reporting by the various desks/projects/teams?

Once ticket is handed over, does it become their sole responsibility to action and close?

Is the master Service Desk able to still see the ticket and report on it for management reporting and housekeeping purposes?

Thanks again Mike, this is really useful.

Kind regards

Ann

[Mike Rathwell]

Hi Ann,

In my case, once I've handed off, it becomes a SEP (Somebody Else's Problem) and I close the ticket. That said, I do retain the link so I can see what happened if it ever comes back to me.

However, if you get really creative (and Jira Misc Workflow Extensions plugin will help a lot here), you can start to do things like, for example:

1. Ticket comes into the master, is adjudicated, and handed off to the target project with a link created between the two of them.
2. Master could go to, for example, an "In Work" status and sit there waiting for something to happen in the target project.
3. When the handed off ticket is completed in the target project, have the transition to "Done" contain a post function (JMWE) that transitions the linked issue.

You'll probably have to dig for an app that extends JQL (or just go with ScriptRunner which has the extensions and a ton of other things that you will end up needing eventually) so that queues in your master can look for issues with linked issues of a certain type in a certain project with a certain status.

[Nicole]

Hi Mike

This is so useful and helpful, thank you so much.

I have had a dig around on my sandpit project and I am struggling to see the process of how to achieve the Field and Screen update, to achieve the object below, can you send me a quick idiots guide please :)

• Created a custom field with radio buttons to select where it was going and put it in a simple screen to be used for transition.
• Using either "Create on Transition" or "Jira Misc Workflow Extensions" (both are great for this), created a "Hand-off" transition that uses that hand-off field in the transition screen.
• The post-function for "Hand-off" conditionally creates an issue based on the value set in the hand-off field, copies across summary with "Handed off from X project" appended, the description, and allows for a comment
• Create a link between the original and the newly created issue.
• The transition takes the original to a "done" state

This would be massively helpful.

Many thanks

[Mike Rathwell]

Hi @Ann Farrant 

I'll see if I can get enough detail in here to get you started on this

1. Created a custom field with radio buttons to select where it was going and put it in a simple screen to be used for transition.
   1. Create a new screen called "Handoff Transition Screen". Don't bother to put anything in this as we'll add it later on.
   2. Go to Jira administration and make a new radio button type field called "Handoff". In that, make the choices be the projects you want to hand off. They don't have to be exactly the name; something that is meaningful to you to use during transition. You'll be using these to conditionally make the new issues. For the time being, for this little guide, we'll call em (original I know) "Project A" and "Project B". Add that to the screen you just created when prompted for which screen to put it on.
2. Using either "Create on Transition" or "Jira Misc Workflow Extensions" (both are great for this), created a "Hand-off" transition that uses that hand-off field in the transition screen.
   1. Make sure either "Create on Transition" or "Jira Misc Workflow Extensions" is installed. If you have to pick just one, I'd go JMWE as it has other things that it'll do for other stuff in your instance. 
   2. You'll probably want to make a link type that is suited to this. I made a "Creates" link type with the outward being "Related Issue Created" and the inward being "Created by Related Issue"
3. The post-function for "Hand-off" conditionally creates an issue based on the value set in the hand-off field, copies across summary with "Handed off from X project" appended, the description, and allows for a comment
   1. Create a new transition from wherever you like in your workflow to do the handoff and make it go direct to "Done". A lot of time, the right place to begin is right from initial issue creation.
4. Create a link between the original and the newly created issue.
   1. For that transition to "Done", edit the Post Functions and add (specifics depends on which add in you are using):
      1. Using the value in your "handoff" field, make a hand off to that project. Specify the target project as the destination. (note you need to make as many of these PFs as you have projects to hand off to; but they are conditional based on your handoff field)
      2. Create the link between the two (this is optional but helps keep track of there tickets went and where they came from)
      3. Copy across relevant fields; I suspect that Summary (with some text added), description, reporter, and any comments are meaningful INCLUDING the transition comments. Note that you don't necessarily have to have matching fields in both projects; you can pick a source field and a target field to put them in. JMWE is a bit better at this.
      4. Add another PF that sets the original issue "Resolution" to "Done".
5. The transition takes the original to a "done" state

Depending on which app you add to your instance, they have a lot of good documentation on the nitty gritty but at least this is the framework to look for the specific destructions.

[Nicole]

Thanks Mike

It turns out we do not have "Create on Transition" or "Jira Misc Workflow Extensions"  so I am looking into whether we can purchase one of these.

However, my question is, what is the benefit of setting up separate Service Desks and not just having different queues in one Service Desk?  Is it the transfer of responsibility and reporting options which are the main benefits?

Many thanks

[Mike Rathwell]

Hi @Ann Farrant 

First, if you're only going to be able to get one of those plugins, I'd recommend getting JMWE. It does the function we're speaking of and adds a ton of other things (validators, conditions, and post functions) that are highly useful as you build out your environment. That is my primary "go to" toolbox of things when I am trying to do stuff.

To your question, it's largely a personal preference kinda thing. That said, splitting the SD into separate HDs has other benefits. I tend to split (in my world) the technological HD from the general office/facility support HD. That gives me a cleaner methodology to separate different function types and it makes it a TON easier to have different permission structures based on who needs to see what, when. It also allows one to tailor the headers differently and the words at the top to help the users know what is where.

[Marlene Koh]

Hi @Mike Rathwell 

Was quite interested in your answer regarding having multiple service desk projects so service a ticket.

What happens if the customer comments on the original ticket? will then the newly-created handed-off ticket have the same comments? 

[Mike Rathwell]

Hi @Marlene Koh ,

Short answer is that I don't copy them across. Rather, I link the tickets and make any that can't see it because permissions able to see because Request Participants.

Longer answer is that, should you want to do that, there are ways to copy from one to the other as part of the post function that clones off the content to a new handed off ticket. JMWE would be able to root those out and move them over (don't have the code to do that at hand as I haven't done that but I do see that it can be done.

Almost always, it isn't a thing for my environment. If it gets handed off it's because the requestor didn't read the preamble to the request types telling them what it was for and simply made the request in the wrong place. Many shops just cancel it with a kurt "You shoulda made this kind" comment but I went for better customer service to let my agents put it where it belonged on behalf of the customer.