JIRA as a Support System

Added by Scott Farquhar, last edited by roytjie [atlassian] on Dec 04, 2008  (view change)
JIRA Documentation

Index
This document is a work in progress. Feel free to add any comments at the bottom.

JIRA can be used as a support system. This document shows how to set JIRA up as a support system.

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'.

Advantages of using JIRA

  • 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

Permissions

A support system has different need 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:

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.

Issue level security (Enterprise only)

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.

Reporter only permission

You can set up the permission schemes so that only the reporter of an issue, and the support staff can see the issue. This means that each user can only see their own users, and is very suited to an internal help desk system, or any other support system with a large number of end users.

Allowing write-only access

If you have JIRA Standard or Professional and need to let customers raise issues, but not see each others', then it is possible to redirect users to a custom 'thank you' page after raising issues.

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.

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:

  1. 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.
  2. 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.
  3. 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.

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.

  1. End-users: company workers place phone calls to the 'hot-line' team.
  2. Hot-line: answer the end-users and open a ticket for every issue
  3. 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.
    1. Technical 2nd level help desk
    2. Functional 2nd level help desk
    3. Logistic 2nd level help desk

The best way to setup JIRA for the above environment is to create a separate JIRA project for each of the four support groups (one 1st level support team and three 2nd level support teams). It would also be useful to create a separate permission scheme for each project so that permissions can be managed for each project separately. For more information on permissions please see:
http://www.atlassian.com/software/jira/docs/latest/permissions.html

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:
http://www.atlassian.com/software/jira/docs/latest/customfields.html

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:
http://www.atlassian.com/software/jira/docs/latest/issuelinking.html

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:
http://www.atlassian.com/software/jira/docs/latest/ldap.html

JIRA's customisable workflow can also be very useful:
http://www.atlassian.com/software/jira/docs/latest/workflow.html

The workflow can be customised for each project (in JIRA Enterprise), 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:
http://confluence.atlassian.com/pages/viewpage.action?pageId=11764

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:
http://www.atlassian.com/software/jira/docs/v3.1.1/extending.html

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.

Sample Escalation

For an example of code that uses JIRA's API to escalate issues please see: Simple Escalation.

Further Customisation

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.

See Also

All Best-Practice Discussions

JIRA as a Support System
JIRA as a Project Management Tool

Labels

best-practices best-practices Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (12)

 

  1. Mar 23, 2005

    Ben Naftzger says:

    The best way to setup JIRA in for a help desk environment is to setup a project ...

    The best way to setup JIRA in for a help desk environment is to setup a project for each 'helpdesk topic'. If you like you can then group the projects into project categories (an Enterprise specific feature). Each project can then have its own permission and notification scheme as well as workflow (multiple custom workflows are an Enterprise specific feature). This will allow you to control access to specific 'helpdesk topics' and ensure that only relevant contacts are notified. You can read more about permission and notification schemes here:

    http://www.atlassian.com/software/jira/docs/latest/permissions.html
    http://www.atlassian.com/software/jira/docs/latest/notification_schemes.html

    Most users would like to record, on whose behalf a helpdesk request has been created. This can be done in two ways:

    1) When an issue is being created, set the reporter so that the reporter field of the issue is the actual customer. Then use a custom field of type 'user' to record the name of the helpdesk person who actually created the issue.

    2) Leave the reporter of the issue as the helpdesk person - use a custom field of type user to record the actual customer.

    JIRA can then be used to generate statistics such as the number of issues created by each helpdesk staff member and/or each customer. You can use a single group by report to do this (http://www.atlassian.com/software/jira/docs/latest/singlelevelgroup_report.html). You can also use a Portlet to display this information (http://www.atlassian.com/software/jira/docs/latest/projectstatistics_portlet.html).

    In JIRA Enterprise, each JIRA project issue type can have its own workflow so that the business process of each helpdesk request can be mapped to JIRA accordingly. For more information on JIRA's custom workflow please see: http://www.atlassian.com/software/jira/docs/latest/workflow.html

  2. Sep 06, 2005

    Aggelos T. Paraskevopoulos says:

    I was wondering if it's possible to setup a Jira professional edition in a simil...

    I was wondering if it's possible to setup a Jira professional edition in a similar fashion to support.atlassian.com or we need to buy to Enterprise Edition?

  3. Sep 06, 2005

    Nick Menere says:

    We use a few Enterprise only features in our support website, namely Issue Level...

    We use a few Enterprise only features in our support website, namely Issue Level Security This is only available in the Enterprise Edition.

  4. Jun 27, 2006

    Karl-Koenig Koenigsson says:

    There is one problem with JIRA as a support system: there is no easy way to let ...

    There is one problem with JIRA as a support system: there is no easy way to let users just email an issue and get a confirmation as well as progress report back the same way.

    The problem is that JIRA only allows registered users to be watchers of issues and in this case is this not sufficient. The background is the security model of course, but you will have to agree that it would be nifty if there was a way to either (bad idea since it clutters the user database) automatically sign up the originator of an email issue or (much better) just use the originators email address as a cc: in all email transactions.

    So, as much as that all life cycle and escalation mechanisms are there, have I come to the conclusion that for this particular task is JIRA not that well suited. This has to be the only case...

    1. Jun 29, 2006

      Dylan Etkin says:

      Hi, I take your point, but I should point out that if you are feeding email int...

      Hi,
      I take your point, but I should point out that if you are feeding email into your JIRA instance via one of the email handlers, such as the CreateIssueHandler, then you do have the option to have JIRA create a user based on the incomming email address. You need to set the createusers flag to 'true' when configuring the service. This will have the following effect:

      If a message comes from unrecognized address, create a new JIRA user with the user name and email address set to the 'From' address of the message. The password for the new user is randomly generated, and an email is sent to the new user informing them about their new account in JIRA.
      Note: this parameter is not compatible with reporterusername. If createusers is set to true, and the reporterusername is also supplied, users will be created if they cannot be found using the from addresses of the received messages. That is, the reporterusername will be ignored.
      By default (if not supplied), createusers is set to false.

      I think that would satisfy your requirement although, as you point out, it will cluter your user table.

  5. Aug 02, 2007

    Hamish Willee says:

    My company uses Confluence for hub of our Wiki and developer support forums. My ...

    My company uses Confluence for hub of our Wiki and developer support forums. My team uses another defect management product as a support helpdesk for our partners. I'm in the early stages of investigating how/how well Jira might integrate with Confluence with for this purpose.

    So

    1. How hard is it to set up single sign on so that when someone logs into Confluence who is also eligible to see the helpdesk, the helpdesk link is visible and there is no need to do additional login

    We support about 100 partners. All accounts in a partner must be able to see and comment to each other's posts, but be invisible to other partners. Currently administration is quite slow as there are so many settings that need to be specified for each new project/access

    2. Is there are way of creating a new partner with "template" permissions over a new project? ie automation of new project creation and associated group?

    Technical support is charged. Currently time spent on an incident is recorded both with the incident and also in a master record which the partner can see and use to track their total expenditure. When the master record decreases to zero, the partner is no longer able to post new requests, although they can see and comment on existing requests.

    3. Is there any way to implement this sort of functionality on Confluence?

    Thanks for your help!

    Regards

    H

    1. Aug 02, 2007

      Eddie Kua says:

      Hello Hamish, This is related Confluence issue. Can you please create a support...

      Hello Hamish,

      This is related Confluence issue. Can you please create a support request ticket at:

      Our support engineers will help you in there.

      Cheers,
      Eddie

      1. Aug 02, 2007

        Hamish Willee says:

        Hi Eddie Thanks, I've done so. Part of it is actually Jira issue - the bit abou...

        Hi Eddie

        Thanks, I've done so. Part of it is actually Jira issue - the bit about whether its possible to implement the billing model.

        Regards

        H

  6. Nov 25, 2007

    CYTEXONE says:

    Has anyone been able to successfully setup Jira to bill? It seems everything in...

    Has anyone been able to successfully setup Jira to bill?

    It seems everything including Worklog's are in place, the only thing that needs to be done is a Billed (check box) and a report that shows which tickets need to be billed on.

    Has anyone figured this out?

  7. 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

  8. 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 :-/

  9. 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:

    Typically as an end user you can only see issues that you, or your company has raised.

    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.

Add Comment