As Jira Service Management (JSM) has grown, Atlassian has made several enhancements to bolster its effectiveness as a comprehensive ITSM solution. In this blog post, I’m going to touch on a new area in JSM ITSM projects that many long-time JSM users might not be aware of: the ITSM category divisions for request types. For the purpose of this post, I will assume that you are familiar with JSM basics, but if you aren’t, there are many good articles on the Isos Technology and Atlassian websites!
Atlassian has added a new template to JSM entitled IT Service Management. This project template generates a project with various ITSM hooks and features, and is continuously evolving. In fact, as I was writing this post, a feature appeared with the NEW tag. When creating a new JSM project, it is important to determine up front if this is the template you want to use, because once the project is created, you will be locked into its features and behavior. Fortunately, there are links to documentation as part of the template flow, so you can make this determination prior to clicking the Use Template button.
As I said above, I am going to focus on one aspect of projects created from this template. This is the ITSM categories functionality.
Before talking about the categories, let me assure you that the base request behavior you may be familiar with is still in effect. All request types map to backing issue types. These issue types can back as many request types as you choose in the project. The fields on the request types still provide an abstraction layer on top of backing custom fields, allowing you to specify the text, help text, and whether or not a field is required for a request.
Portal groups are still present as well. Prior to the addition of the IT service management template, this was the preferred way to add ITSM categories to a project. A project admin would define ITSM categories such as Incidents and Problems, then add request types to these portal groups. While this is a workable solution, it isn’t very clean. What I mean by this is that a single request type could exist across multiple ITSM categories. (Does it really make sense to have the same request type used for Change and Incident requests?) Also, using portal groups in this way limits the way requests can be shown to the customer. A customer shouldn’t have to be aware of ITSM categories. They should just know that the portal exists, and requests should be logically grouped in an easy to find location.
On the backend, portal groups simplify things for agents. Without this quick way to find tickets that fall into specific ITSM categories, agents might not be working on the correct items, making the pipeline less efficient. The workaround for this would be defining more complex queues, but that's error-prone due to JSM's lack of parent-child queue hierarchies.
Adding ITSM categories to IT service management projects addresses these concerns. First, in an ITSM project, a request type is created in a single ITSM category. These categories are Incidents, Problems, Service Requests, Changes, and Post-incident Reviews. (This last category is the new tag I mentioned earlier.) While request types retain the previous behavior, at the time of definition they are also added to a single ITSM category. One warning here - once you have defined a request type in a specific ITSM category, you cannot move it to another category. This fulfills the need to have request types exist at the highest level under the singular area in which they function in the ITSM world. This also means that customers don’t need to know anything about this underlying structure - they just need to look for requests that match their needs.
From the agent perspective, a new set of queue groupings has been added into JSM. There is a grouping for each of the ITSM categories. Underneath these groupings, the queues you are used to can be defined, with the caveat that only request types matching the specific ITSM category will appear. This allows agents to view the specific request types they are interested in from an ITSM category perspective without having to formulate specialized queries for that filtering. It's important to note that there is also a general queue group where cross-category requests can be seen.
For more information on how this ITSM functionality, as well as general JSM functionality can help your organization, reach out to Isos Technology.