Ready to set up automatic request routing with JSM? Let's get started!
In a previous article, I gave you the background to the implementation of several technical and business support projects with Jira Service Management (JSM) at a customer site. We covered :
- The organization of the three assistance teams and the difficulties encountered in developing projects;
- The solution adopted to meet my customer's needs (a customizable and extensible common base) ;
- Different tips if you're in a similar situation.
In the next few articles, I'll take you through the concrete implementation of some key elements of the chosen solution in JSM. And we'll start with a very important step in the life cycle of a ticket: automatically directing it to the right people, part one (just like at the movies 🤓 you have to wait to get the rest).
Now it's time to get your hands under the hood!
Disclaimer
Firstly, the solution presented below and proposed to the customer is not THE one and only possible solution.
Photo credit
It's just one of many ways of meeting my customer's needs, and above all, his various constraints. It's completely contextual. The way users apprehended a tool like Jira, the ecosystem of applications already in place, security constraints, and so on.
Then it was built up as we went along. Not all elements were put into production at once. Implementing enhancements as certain needs emerged avoided building a gas factory full of useless features.
This article is not a step-by-step tutorial on how to set up the parameters presented.
Finally, the solution presented was implemented on a Jira Data Center instance, with Jira Software and Jira Service Management in minimum version 8.13. The instance is equipped with various plugins, which have enabled us to implement certain mechanisms and automations:
- Script Runner, a paid plugin that lets you customize Jira using scripts written in the Groovy language. Pre-written scripts are supplied with the plugin, but a minimum of development knowledge is required to exploit its full power;
- Automation for Jira (included in Jira Software and Jira Service Management Data Center). Automation for Jira allows you to build automatic rules easily and visually, in a "when, if, then" format;
- Assets - ex Insight (included in version 4.15 of Jira Service Management Data Center). Assets is Jira's repository module. It enables you to define, structure and manage data repositories, which can then be used in tickets.
Let's go!
In the remainder of this article, we'll refer to the people who handle and process agents' requests for assistance. For reasons of anonymity, the names of agents, teams and departments have been changed.
The principle of automatic orientation: laying the foundations
One of the priorities of the various support teams was to automatically direct a request to the right people as soon as it was created, without having to go through an initial qualification "gate". To achieve this, we had to :
- Understand how agents are organized and grouped, as well as their areas of intervention;
- Enable users to pre-qualify their requests independently, by entering the necessary information directly in their request;
- Set up a routing table to describe the combinations of criteria and which agents they concern in the support teams.
Modeling assistance cells
In our discussions with the three support teams, we observed that agents were grouped together by area of business or technical expertise. These groups were called "assistance cells".
Each support unit is responsible for handling requests within a given perimeter. But it's also important to bear in mind that each has its own management preferences.
We therefore need to represent this notion in Jira, with the possibility of managing the specificities of certain cells. We also need to bear in mind that we have three separate support teams, each with a slightly different way of working.
The final choice was to use Assets to set up an assistance cell repository.
Action 1 - Creation of a repository of assistance cells in Assets
As a prerequisite, you must have created an object schema in Assets.
One or more object diagrams?
Initially, we had chosen to bring together the support-related objects in a dedicated schema. Today, we're thinking of migrating these objects into a more global schema grouping together applications, services and processes, as they all share common notions and are strongly linked.
There's no right or wrong way to do it, in my opinion. Choose what you think is the most coherent, in terms of management, authorizations and links between objects.
To benefit from a common structure between each team, while still being able to extend the attributes of a given team, we're going to exploit the Assets inheritance feature.
Inheritance simply means creating a parent object type in your object schema, followed by child object types that inherit the attributes of the parent. The parent therefore carries the attributes common to all child types.
It is then possible to add additional, independent attributes to each child object type.
As our parent object type is not intended to represent objects directly, we make it abstract. This means it's not possible to create objects directly at parent level.
We therefore create a first type of parent object Support unitwhich carries all the attributes common to all the cells in the three teams:
- A name
- A status
- List of agents in the cell
- A generic email address
- The ability to disable cell notifications
- Notification mode (generic email address only, agents only, both)
We then add three types of child objects representing the specific features of the cells in each of our three assistance teams: Strawberry support unit, Apple support team and Pineapple support unit.
The Strawberry team needs to know to which department each cell belongs. On the Pineapple team, they want to identify for which region of the world each cell operates. We therefore add complementary attributes to these two teams.
The advantages and disadvantages of inheritance in Assets
➕ We like:
- All child objects can be viewed directly from the parent type;
- Common elements need only be configured once;
- It is then easy to search directly from the parent type;
- Technically, the attribute identifier is identical for each child, which is very practical when writing scripts.
➖ We like less:
- All children must inherit all parent attributes;
- Parent attributes are displayed first; it is not possible to position a child-specific attribute in the middle of the parent attributes, which sometimes makes it difficult to read the creation/modification forms;
- Once you've chosen to start with heritage (or without), it's very difficult to go back.
We now have a repository that groups all our assistance cells by team. Here is the result:
Defining the service catalog
Once we've identified the various support units, we need to build our service catalog, i.e. a list of all the services offered by each user support unit.
But what is a service?
There is no simple, universal answer. A service can take on different definitions depending on the company or organization, its context, its business. And sometimes even depending on the support team. In our case, we had to find a definition common to all three support teams, but one that could be extended. And so it was that this catalog naturally took its place in Assets, alongside the support cells.
Action 2 - Creation of a service catalog in Assets
As with assistance cells, we use inheritance to create a common service structure that can be extended by team. We therefore create a first object type Service support formunder which we will present our three teams: Strawberry service, Apple service and Pineapple service.
We worked with our teams to define a service: a service is an activity offered within a given scope. The activity can be technical assistance, business assistance on an application, business expertise, data processing... The scope can be very varied and correspond to a business, an application and its modules, or an expertise.
We have therefore chosen to work with "generic" attributes that can cover all these notions, without stepping on each other's toes or setting up an ultra-complex structure:
- The activity corresponds to Service type ;
- The perimeter is identified on two levels Category and Subcategory.
As categories and sub-categories can sometimes overlap, we have chosen to create a single common list in the form of an object type, grouping together all possible values. This avoids duplication during searches, exports, etc. We also create an object type to manage the list of service types.
We can use both types of object in our service cards. A service record is described by :
- A name
- A status
- A type of service
- One category
- A sub-category
- A responsible assistance team
The label in Assets
It's mandatory for every type of object in Assets to have at least one "label", in text format. Any attribute in text format can be identified as the object's label. The label may or may not be unique. It is used to represent the object in screens, references, certain lists... Hence the importance of having a clear and representative label for your object.
We have also added additional data from external repositories, such as the application concerned or impacted by the service, for example.
We've just added our service catalog, i.e. all the service sheets for the various support teams. Here's the result:
For example, here is an extract from the service sheets for material requests:
Creating fields based on Assets
Having data in Assets is great. But it's even better to be able to use them for assistance requests! To do this, we need to create and parameterize various fields that will be fed by our Assets repositories.
First, we need to identify the fields we need:
- A field for associating an assistance cell with a request;
- Different fields for selecting combinations of service criteria ;
- (optional) A field for associating a service record with a request.
Note: we have chosen not to set up a Service sheetHowever, if, for example, you want to analyze the number of requests for a given service, it's a good idea to include this field. However, if you wish to analyze the number of requests for a given service, for example, it would be useful to include this field.
Action 3 - Creating and setting Assets fields
The first field set up is that of the assistance cell. This is a simple field of type Object Assets. According to the assistance project (one project per team), I need to pull up the list of active support cells in the team.
To set the parameters for each project, I use Jira's notion of "field context". So I create a specific context for each project, and for each one, I adjust the field settings to point only to the type of object corresponding to my team's support cells. For example, in the case of the Apple team :
The advantage of using contexts is that you can customize the query according to the project. For example, the Pineapple team would like the support cells to be presented in order of region of intervention, and not in alphabetical order. It also wants to see only those cells authorized to intervene on the service identified on the ticket:
${Help desk} is a pointer to the Help desk which we'll create below. Imagine that when the list is loaded into a ticket, ${Help desk} field will be replaced by the label of the object selected in the Help desk.
Difference between "Filter scope" and "Filter ticket scope".
In the first case, the filter is absolute: only values matching the filter will be authorized for the field. When performing an advanced search on the field, auto-completion will only propose these values. The context of the ticket is not taken into account.
In the second case, the filter is based solely on the context of the ticket at time T. It is possible to use the value of certain ticket fields in the filter.
If you have values that were active and in use at one time but have become obsolete, you still want to be able to report or search on them: it's therefore more practical to filter on the status of an object, for example, in the Ticket perimeter filter.
Let's now create the fields to identify the service form concerned by a ticket. We saw earlier that a service is defined by three criteria:
- Service type
- One category
- A sub-category
We also know that for a given type of service, there are only a limited number of categories available. Indeed, it wouldn't make sense to offer all categories, knowing that only some of them provide a winning combination for a service listing. The same applies to sub-categories.
We therefore need to create three "cascade" fields, with the second dependent on the first, and the third dependent on the first and second. The difficulty lies in deducing which values depend on each other. Indeed, this dependency is carried by the service records. However, we want to reassemble our service types and categories, previously created as dedicated object types.
We will therefore exploit the notion of relationships between objects in Assets :
- A service type is "valid" if it is associated with at least one active service record;
- A service category is "valid" if it is associated with at least one active service record whose service type is the one previously selected;
- A service sub-category is "valid" if it is associated with at least one active service record whose service type and category are those previously selected.
Thanks to the Assets inboundReferences() (inR() for short), it's possible to search for all objects with an incoming relationship from an object meeting certain criteria. You can find further examples and information on searching in Assets in the editor's documentation: Advanced searching: AQL - Assets Query Language.
Here's an example of the configuration of the three fields for the Strawberry team:
Why not use Assets fields " referenced " ?
Assets provides a custom field type Object Assets referenced which allows direct dependency on another field Object Assets simple.
Assets' referenced fields bring several limitations and did not convince us:
- When the field is created, you must choose whether it is multi-select or single-select. Object Assets which allows you to modify these settings on the fly and according to the context;
- Dependency only exists on one level: it is not possible to have a referenced field dependent on another referenced field.
However, it should be noted that the use of single fields Object Assets induces a non-negligible constraint: when the value of a parent field is modified, the dependent fields are not reinitialized. It is therefore possible, unless otherwise managed, to have inconsistencies in the selection of values. This anomaly has been identified by the editor, but has not yet been corrected.
This problem can be circumvented with a simple script of the type Behaviour Script Runner plugin, for example. You can also consult the publisher's documentation to find out more.
So we now have all the data we need to set up our automatic orientation. 🙌
And now... what am I going to do? 🎶
Well, we've done the easy part... and it's time for a break.
In the next article, we'll get down to the nitty-gritty of what we've been doing all this for: setting up all the elements needed to automate the routing of requests to the right helpdesk. Beware, it's going to be a lot more technical.
We'll also be taking the opportunity to extend our thinking a little and see how we can go even further with complementary repositories, well-configured queues and so on.
Cover illustration by pch.vector on Freepik
