This document shows how to set JIRA up as a support system:
JIRA Advantages
- By using one system for support and bug / feature tracking, you can link support issues to the bugs that they reference.
- JIRA is a very simple system to install and use - there is very little training required for support staff, or end users
- JIRA's configurable workflow adapts to your existing support processes
Feature Setup Instructions
Note that some terminology is different between the two systems - for example a support system typically uses the word 'ticket' where an issue tracking system may use the word 'issue'.
Permissions
A support system has different needs for permissions than a bug tracking system. Typically as an end user you can only see issues that you, or your company has raised. The ways of doing this are:
1. Different Projects
At a very simple level, if you are supporting a very limited number of clients, you can set up a different project for each of your clients, with a different permission scheme for each project.
You can set up the permissions so that only the reporter of an issue, and the support staff, can see the issue (i.e. give the 'Browse Projects' permission to the Reporter and appropriate internal groups). This means that each user can only see their own issues, and is very suited to an internal help desk system, or any other support system with a large number of end users.
2. Issue Level Security
You can set up different security levels for each customer. This is similar to having different projects, but allows the support team to manage the issues in just one project.
Work Queues
Often in support systems, the priority of an issue is not as important as the order in which the issues are raised. There may be a Service Level Agreement in place, which specifies that an issue must be responded to within a certain time.
The JIRA toolkit will show you whether the last commented was from a JIRA Administrator, or whether it was from a customer. This allows issues to be prioritised by the order in which they need a response.
Email Integration
JIRA can easily be set up to handle incoming email, and create new issues, or comment on existing issues. It also sends mail notifications to users when the issue has been updated.
When setup this way, the client can create and comment on an issue, without having access to JIRA.
For more information, see the documentation on Setting up email integration in JIRA — particularly the CreateOrCommentHandler.
Custom Landing Page
You are able to setup a supprt-friendly landing page explaining how to log tickets using the Improved HTML Plugin.
Support Knowledge Base
Please see Adding Knowledge Base Functionality To JIRA.
Log Phone Calls To Tickets
Please see Logging Phone Calls In JIRA.
SLAs
Most SLAs are very specific to a particular organisation, so it is difficult to ship a completely out-of-the-box solution with JIRA that will meet everyone's needs. However JIRA has 2 approaches that can be used separately or jointly to meet SLAs:
- The most powerful approach is to write a Jelly script (sample available) which invokes a saved search (filter), and loops over the issues, adding a comment, transitioning them to a new state (e.g. "Requires Response"), or otherwise letting people know that action needs to be taken. This Jelly script would then be run periodically by a Jelly runner service. Atlassian uses this approach on https://support.atlassian.com, to automatically close issues that have not been replied to in X days. We have a filter returning issues in status "Waiting for Customer", updated from any time to 1 week ago (i.e. not touched in the last week), and these are transitioned to "Inactive", which triggers an email letting the customer know.
- Create a search filter that finds all issues that meet a certain criteria. Save this filter and subscribe to it, either by email (through JIRA) or by subscribing to the filter's RSS feed in an RSS reader. This way JIRA will notify subscribers what issues are 'outstanding'. For more information on creating and saving filters and subscriptions please see this page. There is also a short video on Simple SLA with Filters.
- If a Jelly script cannot do what you want, or JIRA's searching capabilities are not sufficient to match issues you want, you could write a custom service that locates issues that meet a certain criteria and then does something with matching issues. For example, a service could reassigns the issues to another team member (e.g. project's lead), increments priority, sends notifications, etc. For more information on JIRA services please see this page.
Escalate Tickets
For an example of code that uses JIRA's API to escalate issues please see: Simple Escalation.
Change Status After Comment
A user adding a comment via the JIRA UI can be prompted to change the issue status. The source is not yet available as this is currently a work in progress but please visit Adaptavist for updates.
Example Scenario
Here is an example scenario for a support environment within an organisation and suggestions on how to setup JIRA to fit this environment.
- End-users: company workers place phone calls to the 'hot-line' team.
- Hot-line: answer the end-users and open a ticket for every issue
- 1st level Help Desk: analyse hot-line tickets, and close them if they are able to respond themselves. Otherwise they dispatch the ticket to one of three 2nd level help desk teams.
- Technical 2nd level help desk
- Functional 2nd level help desk
- Logistic 2nd level help desk
Managing Project Permissions
The hot-line team will create a new issue in the 1st level support team's dedicated project (referred to as 'hot-line' project from here on) for every call they receive. The way the hot-line project should be setup depends on whether the actual end users need to see JIRA issues. If yes, ensure that every member of this hot-line team has Modify Reporter permission so that they can set the 'reporter' of the issue as the actual end caller.
It is also possible to create a custom field of type User which can be used to track who (which member of the hot-line team) actually created the issue. The hot-line team member will have to populate this field with their username. For more information on custom fields please see:
Adding a Custom Field
You can then give the Browse Project permission in the hot-line project's permission scheme to the 'Reporter' role (please see the permission documentation referenced above for more details) and 2 user group . One user group will represent represents the hot-line team and the other the 1st level support team. This way, the end users can see issue created on their behalf, but not issue's created for other users. The hot-line group members and the 1st level support team will be able to see all issues in the project.
If the actual end users do not need to see the issues in JIRA it is probably better to not give the Modify Reporter permission to anyone for the hot-line project. The reporter field of the issue will then automatically default to the logged in user (i.e. the hot-line group member who is creating the issue). A custom field of type User can still be created and used to record on whose behalf the issue was created. The field will have to be populated manually during issue creation. This custom field can also be made 'required' so that it will have to be populated during issue creation.
The user group representing 1st level support team should be given the resolve and close issue permissions so that they can resolve/close issues once they are dealt with.
I also recommend setting the 'Assignable User' permission in the hot-line permission scheme to the user group representing the 1st level support team, so that issues can be assigned to them. The 'Assign Issue' permission can be given to the hot-line group so that its members can assign issues to specific 1st level support team members.
Alternatively, the 'Assign Issue' permission can be given to only the 'Project Lead'. The default assignee of the hot-line project can be set to 'Project Lead' or 'Unassigned' (if unassigned issues are enabled. Then the hot-line project's lead can go through all the issues assigned to him/herself or all Unassigned issues and assign them appropriately.
If the 1st level support team members cannot resolve an issue they should create a new issue in one of the other three projects (the technical support project, the functional support project, logistics support group project) to
indicate that the issue has been passed to the 2nd level support. For this to occur the 1st level support team must be given the 'Create Issue' permission in the permission schemes used by these projects.
The issues created in the 2nd level support projects should be linked to the issue in the hot-line project
using Issue Links:
Each of the 3 support projects can be setup as required by each team, in terms of their permissions, notifications, workflows, etc.
If all internal users are stored in a LDAP directory, please take note of JIRA's LDAP integration:
JIRA's customisable workflow can also be very useful:
The workflow can be customised for each project, and can be used to better reflect the business process of each support team in JIRA. For example, if issues can only have 2 stages (Open and Closed) then it is far better to create and use a custom workflow rather than use the JIRA's default workflow.
Using JIRA's flexible plugin system it is also possible to extend JIRA's functionality in regards to workflow. One place where this can become useful, is when closing issues in the hot-line project that have linked issues in one or more of the 2nd level support projects. It is possible to write a custom Workflow Condition that will look at all the linked issues and only allow an issue to be Closed when the linked issues are also closed. This will ensure, that the issues in the hot-line project
are only closed when the linked issues are handled by the respective 2nd level support team. For more information on creating custom workflow elements (e.g. Workflow Conditions) please see:
How to create Custom Workflow Elements for JIRA 3
If one of the support teams also has an existing support system in place that they would like to continue using, it should be possible to integrate that system with JIRA. JIRA has a number of extension points that can be used to communicate (and hence integrate) with external systems:
By default, JIRA related issue links do not affect workflow, so users can close issues even if other open issues are listed as blocking it. You can enforce the rule that all blocking issues must be resolved before you can resolve the parent issue using the custom 'blockingLinksClosed Condition' workflow plugin.
Further Support Discussion
Related Best-Practice Discussions
Confluence UI Guidelines
|
|
Confluence UI Guidelines
|
|
Confluence UI Guidelines
|
|
JIRA as a Support System
|
|
Confluence UI Guidelines
|
|
JIRA as a Support System
|
|
Using JIRA for Agile Development
|
Comments (4)
Dec 10, 2007
Craig Pugsley says:
After going through this process ourselves recently for an internal proof-of-con...After going through this process ourselves recently for an internal proof-of-concept, we came upon a few stumbling blocks - the most confusing of which was creating the service to listen to new emails in a support mailbox and create (or comment) on new issues automatically from them.
When creating the new 'com.atlassian.jira.service.services.imap.ImapService' service, it is important to configure the 'handler.params' value 'issuetype' correctly. We had created new issue types and removed all the old ones. Therefore, all the new issue types we had created had new ids associated to them, and it wasn't easy to determine what these new ids were. I'm not even sure you can, from the UI.
In the end, we looked at a backup XML export for where it declares the issues types, and the ids were listed there.
Overall, our proof-of-concept is going extremely well
Jan 16, 2008
Matt Doar says:
The original article needs a spell check and some editing so it doesn't read lik...The original article needs a spell check and some editing so it doesn't read like a cut and paste from some customer :-/
Jun 13, 2008
Bradley Wagner says:
This is a great article. I can't believe its taken me this long to find it. I ha...This is a great article. I can't believe its taken me this long to find it. I had one question with respect to permissions on 'tickets'.
The articles states:
We employ the "Reporter only permission" strategy but have found it cumbersome when trying to allow other members of an organization to share tickets among them. Ideally we'd like everyone in an organization to be able see/modify any Tickets that anyone from their organization has created.
Thinking about this logically, it makes sense that in order to do this all the users would would have to be a in group of some kind and that there would have to be a security level pertaining to that group, a permissions scheme for that group, or a separate project per group. None of these seem very scaleable as it would require creating new groups, permissions schemes, projects every time a new customer is signed.
I did see one possible alternative to this on support.atlassian.com which involved adding specific users as CCs or participants on a particular issue. Can anyone shed any light on what exactly this feature does? I'm currently using JIRA 3.6.3 Enterprise and have not seen those fields before.
May 21, 2009
Andrew Myers [Atlassian] says:
Hi Bradley, The CC field is just a Multi User Picker custom field. We then add ...Hi Bradley,
The CC field is just a Multi User Picker custom field. We then add the CC field to the Notification Scheme for the project, and also to the Issue Security Level.
Kind Regards,
Andrew [Atlassian Support]