Does JIRA Service Desk use different rules for assigning issues?

[Paul Alexander]

No, I haven't yet started a trial of the JIRA Service Desk product, but I have a basic question as part of the evaluation I'm doing. Does this product use any different rules to assign issues to groups or multiple users than is afforded within the JIRA product? It seems critical in a service desk environment to be able to do this...as opposed to development work where one person owns the story and several developers have subtasks to accommodate the work. Please share your experiences or other pages I should be reading - anyone using this new offering from Atlassian. I'm very excited about it, but frankly, unsure how I'm going to trial it in my production on-demand instance w/o inviting tons of emails/concerns from my user pool:|.

I am familiar with the few options on this page to assign issues to multiple users - again, just need to know if service desk offers anything different.

https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users

Thanks!

[Deb Martinez · Accepted solution]

Paul,

Is it really critical to ASSIGN the issues or just NOTIFY certain people? Service Desk is built on JIRA, but they did include an additional feature called Queues. You can create a queue for a small group of users for example, so that any new issues that come in for that team show up in the queue. That's the only way I can think of to interpret "assign issues to GROUPS".

If it is notifications that you are really after, I am implementing Service Desk now and am suggesting the teams use subscriptions. They can create filters for the clients/users/products they support and create subscriptions for things they want to know about.

[Paul Alexander]

Thanks, Deb. Queues...it sounds like I need to read up on this. I finally found the product's documentation (URL below). As I interview folks as part of the effort to either re-platform our IT helpdesk solution or get off of it and go with Atlassian's Service Desk, power users on the helpdesk front expect to be able to assign issues to a group; our current, custom system (yes, I said, custom, as unbelievable as that sounds) shoves a notification via email out to everyone on that group when an issue is assigned to it. Someone goes in and accepts the ticket. I'm starting to see that our old approach probably isn't needed.

And I'm starting to like the idea of having issues "Unassigned" as they come in. The Agile Coach in me says this is a bad idea. I think for development, all issues must be assigned to be entered into the sprint, but for the service desk, perhaps we don't need that. I do like your approach of using subscriptions against specific filters. I suppose shoving a few filters onto a dashboard and making the service desk use them as a means of advertising the "unaccepted" issues is the way to go...the service desk can then pick up and take ownership of issues. We use wallboards so I see a lot of value there, too.

I'd like to stay in touch with you as you deploy service desk. Like I said, I'm currently tasked with proving Atlassian can support our core IT service desk's needs. We have JIRA, Confluence, Bonfire, Team Calendars, etc. Issue Collectors will be another great way to bring issues from customers into the system directly from our apps.

https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+Documentation

[Paul Alexander]

@DebHines, another question...

For each Request Type that you setup, is each mapped to an Issue Type in JIRA? What's your experience so far (do you use a single Issue Type for each Request Type, or just simplify it into one or two Issue Types)?

Something else I just thought of...I need to delve deeper into Atlassian's instance and see how it uses the product. I've been there a lot, but hadn't thought of using it as a guide:-).

[Deb Martinez]

Oh the multiple projects piece is a little tricky. If your users are already in JIRA, then it probably doesn't matter too much because they will use the standard JIRA view and use the Service Desk tab. But if your customers want to use the Customer Portal (like mine), it's a separate URL for each Project. Which is a limitation that I don't like. So for now, we are just dealing with it since the Implementation phase is temporary. But we would prefer to be able to have the user login to ONE customer portal and the permissions dictate which project portal(s) the user would see. Maybe a future enhancement... :-)

[Paul Alexander]

Grumble...your preference seems spot on - that's quite a deficit. I really need to chew on this now...thx for your valuable time so far.

[Deb Martinez]

Here's what I can tell you about our setup. Keep in mind, we are using ours for software support for external clients and not for IT, but I think you can see the picture.

We have two projects - one for Ongoing Support and one for Implementation - each which have a different customer portal URL. Our Ongoing Support is the only one we've configured so far.

I am actually only using one issue type for Ongoing Support (Incident), but we will add at least one more for Implementation (probably Project or Task or something). Now, we have about 10 different products that are all supported through this portal. I added the product names in the Components field and then I have a form for five different groupings for the products. (ie. Form1=Report an issue for ABC Product, Form2=Report and issue for DEF Product). You can hide the Component field so that it is pre-populated with "ABC Product" when they choose Form1.

As for password resets, etc. I have one scenario where I created a separate form. We wanted a special way to report System Outages. I created a form just for that (regardless of Product), where I hide the Priority field but prepopulate it with "Critical" and then just ask the user to select the product from the Component drop down.

[Paul Alexander]

Ahh ha. Thank you. That stirs the pot. I need to chew on this.

[Deb Martinez]

Hi Paul,

My users have that same issue - they keep thinking they want to be able to proactively assign issues to people. However you should challenge them to think differently. So I went through this too.

Here's how I approached it. So here's how a queue might work. Let's say all tickets that are network related would go to the Network Team. You would create your forms to prompt users to tell you it's network related. For example, you might have a form that is just for requesting access to files/folders/servers/etc. That form could be either for Issue Type = Network or you could even have another field (like Component) that = Network. In either case, this would be configured by you to automatically populate with Network. Now you set up a Queue for all unresolved issues that have either IssueType=Network or Component=Network (whatever method you used).

There is absolutely no reason for the person requesting help to ASSIGN the issue to the team. It's immediately already in the team's queue! Having the reporter assign issues to other individuals is a HORRIBLE practice. I always discourage people from doing that! I tell them, "don't assign a ticket to someone other than yourself unless you've already talked to them and they agreed to work on it!". Here's why: how does the reporter really know who will work the issue? Are they totally confident that only that SINGLE person can work the issue, confident enough that they will wait a week if that person is on vacation?

I am the JIRA administrator but I am also a developer support. Our support analysts are always assigning tickets to people in my team, the people they THINK will handle the issue. Then later in the day (or several days later), they write a complaint to me that their ticket hasn't been handled. When I go to look at it, I notice that they assigned it to someone who is on vacation, or someone who is temporarily assigned to another project, or someone who is working the late shift when they wanted a quick response.

Hope that helps. :-)

As for our project, we are starting Beta on April 1st. Let me know if you have any questions!

Deb

[Paul Alexander]

Thank you so much; very valuable information that will help me.

Deb, another question...

For each Request Type that you setup, is each mapped to an Issue Type in JIRA? What's your experience so far (do you use a single Issue Type for each Request Type, or just simplify it into one or two Issue Types)?

Something else I just thought of...I need to delve deeper into Atlassian's instance and see how it uses the product. I've been there a lot, but hadn't thought of using it as a guide:-).

[Paul Alexander]

Deb, how do you plan to deal with the additional "JIRA projects" needed to support the service desk's needs? Are you in the process of adding one for each possible software system that needs support? Also, how do you plan to deal with requests that come in for basic needs like password resets or file share access (what JIRA project would these be associated with)?

In my case, with 3,300 employees and over 200 supported systems, I need to evangelize how this can work, and what JIRA projects many random issues would get assigned to. Big thanks again for any insight!