JIRA as internal multiple-level IT Helpdesk

[Adam Dyga]

Hi,

We are evaluating whether JIRA is suitable for global multiple-support-levels system (city/country/continent/global levels). The company has offices all around the worlds and needs to provide IT support for their employees (issues with laptops, PCs, networks, etc). We would like to make it work this way (example for China):

1. A user in Shanghai office reports an issue

2. One of local IT admins (in the same office) is notified and tries to solve the issue. If they succeed, the issue is closed, otherwise it's delegated to country level (China) IT Support team (the country-level team gets all issues that cannot be handled in offices directly)

3. The country-level team works the same way, if they can solve it, the issue is closed, otherwise it's delegated to "parent" team, and so on. Finally it may end up at the global HQ level. Also, at any level, the particular issue may be delegated down.

On the other hand, in Europe it has to work the same way, but the support levels and teams have reflect the location appropriately (eg. Berlin -> Germany -> Europe -> Global). Note that the Asia-level support team contains different members from Europe-level team.

What would be the best way to achieve that in JIRA? I've read http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System but it describes a slightly different scenario, and, what's more we would like to keep things as simple as possible, ie. use only one JIRA project.

One of ideas is to create a group hierarchy reflecting the company structure and add a custom field named "Assign to Group". The issue could be delegated to parent/child groups by properly setting this field. Additionally a "Delegate" transition could be also defined (eg. from Open to Open state - not sure if this is OK). During the "Delegate" transition the user would have to change the "Assigne to Group" field appropriately. Is this the right approach or there are better solutions?

Regards,

AD

[Jo-Anne MacLeod]

I would be tempted to do something along the following lines,

Have a workflow transition called "elevate to next tier". When the support person clicks on it, the ticket gets reassigned to that group of people. You can't assign a ticket to more than one person, but if you have a userid in JIRA called "China Support" (for instance) the ticket gets assigned to that "person". Similarly for "Global Support". Then on your dashboard you have a gaget set that shows all of the tickets that are open for the user "China support", or "Global Support". Depending on what group you belong to, you would then view the list, and pull up the next available issue, and say "Assign to me" and begin working on it.

There would be lots of other checks and balances in it, but that is what my first thoughts are.

[Adam Dyga]

I like this solution, the question is how (where) to store the relationships between the userids, eg. "China Support" has a parent "Asia support" and several "<City> support" teams. A user at a particular level should be able to delegate issue only one level down or up, not reassign it directly to a different continent (that's why I thought of using groups to do that and an extra custom field "Assign to Group")

Another question is it OK if "elevate to next tier" transition leads from "Open" to "Open" state? Or maybe adding a new state "Delegated" is better (it's just an idea, but I don't see any advantages of this approach right now).

[Dieter]

In our solution this is handled by the workflow. If the user clicks escalate to next level the issue is transitioned to the next state up. In this new state the step specific permission allows the issue only to be assigned to a member of the level specific group specified by the custom field group_<levelx>. This is defined in the workflow

To be more precise with our solution. The issue has 4 custom fields containing the names of the groups at each level. The group names are

• group_location
• group_ country
• group_region
• group_global

The assignable permissions at the step level is defined as follows

• At level location: jira.permission.assignable.groupCF=customfield_xxx (xxx id = custom field group_location)
• At level country: jira.permission.assignable.groupCF=customfield_yyy (xxx id = custom field group_country)
• At level region: jira.permission.assignable.groupCF=customfield_zzz (xxx id = custom field group_region)
• At level global: jira.permission.assignable.groupCF=customfield_kkkk (kkk id = custom field group_global)

[Edwin Goddard]

Hi @Dieter,

Just wondering how this works on practical level in terms of who's the assignee.

Say I'm in the location team and need to escalate it to the country team. I click the escalate button and then need to pick someone who is in that country team.

With this solution is it possible to put it on a queue for someone in the country team to pick up?

Thanks,

Edwin

[Srini Srini]

This could work as well

1. Every Country is defined as a component and the component has a lead to who the issues are assigned by default

2. The lead's email address will be a distribution list and all the first level support will be in the group

3. Support person, who ever is available will assign the issues and start wokring - this will assign ownership and that is important for me

4. Time frame should be defined when the ticket should be escalated to next level

5. Create a filter that will filter all open tickets based on the above time frame

6. Use jelly script to update issue status (so you can filter later) and assign to the second level support team and this should also be a distribution list (see point 2)

7. Repeat steps 4, 5 and 6 for all levels

Hope I covered all your request.

-Srini

[Adam Dyga]

Thanks for tips. I didn't mention it, but we wanted to use Component field to categorize issues (whether it's software, hardware, etc).

[Dieter]

the solution suggested by me does not require the components, just some user and group custom fields which of course can be hidden to the user

[Srini Srini]

The

* Use a single select CF and define the location name that the user should select based on the location they belong to

* Create groups and the name of the groups should be exactly same as the values of the above custom field

* In the notification scheme select Group Custom Field Value and add the CF to issue create notification. Jira will notify only the people in the group based on the CF value selected by user

I have a project designed on the same basis and it works good

-Srini

[Dieter]

We have something similar. for each support level (location,country,region,global) there exists a responsable user and a team group which can accept issues at the corresponding level.

The user is necessary since we cannot assign issues to groups. So each issue has 4 user and 4 level specific group custom fields.

Depending on the city, these custom fields are populated with the groups. In your example the 4 group level specific custom fields named group_location, group_country, group_region, group_global will be populated with

• team_berlin
• team_germany
• team_emea
• team_global.

We store the relationship location =>[ country,region,global] in a groovy map and populate user/group custom fields in a groovy post function of the create transition.

Workflow conditions use the level specific group custom fields. The workflow actually is pretty linear, with 4 main states, one for each level. we use the workflow step permission defined by the property

jira.permission.assignable.groupCF=customfield_xxxxxx (xxxx id of custom field representing the assignable group at specific level)

to just allow members of the level specific group to become the assignee.