Running a complex IT service catalog in Jira Service Management

In this blog post, we will guide you through our process on how we came up with integrating Projectrak (formerly Profields) for Jira and Elements Connect, and creating an IT service catalog which allowed us to delegate to Jira users the power to add values to a "select list" field. Keep reading.

The Atlassian service management tool has come to be one of the most favorites despite this solution use to come in many forms and styles: from simple customer service portals aimed at the problems non-technical users to sophisticated help desks that support quick, specialized services. Now, what happens to the Jira Service Management when ITSM meets DevOps? Easy, let's start by explaining the problem.

How did we implement an IT Service catalog for a global team of developers?

On the following video, Lara, a former Atlassian Certified Professional of our team, explained to the team of Elements what we did here by delegating to Jira users the power to add values to a "select list" field:

As Lara mentioned in the video, this Deiser customer, a top-tier bank leader in digital transformation and a practitioner of a CI/CD model, recently requested to set up their own internal Help Center with Jira Service Management. And, to say the least, this goes towards the further right side of the spectrum: very specialized services, very demanding internal customers, and very strict SLAs. Since developers are the main internal customers supported, the ITSM scope of Jira Service Management specifically included:

Every tool and piece of equipment needed by developers in the context of a DevOps model: from a Docker container and any other licensed software to servers, laptops...
Integrations among tools and third-party services.
Traditional support for incident & problem management.

Additionally, the Jira Service Management installation was conceived as the embryo for future service desks to be replicated in different countries in order to support local work forces. Whatever we gave them, it had to be robust and manage complexity and concurrent usage with the minimum toll to performance.

When Jira Service Management native functions are not enough...

The service catalogue had barely five objects in the first level but ran deep, sometimes reaching the 5th level. But why wasn't JSD enough?

The requirements: cascading fields and delegated administration

There were two main reasons for supplementing Jira Service Management with additional apps:

Depending from a Jira administrator to change the catalog was unacceptable in a context of constant change and continuous delivery. We needed to empower IT employees to administrate the catalog without being promoted to Jira Admins because the number of services would grow and new service portals would be spawned.
Jira has a cascading custom field that is very often used in JSD service catalogs... but only has two levels. Our customer wanted to use up to 5 levels.

The process to evaluate Atlassian Marketplace Apps that allowed to delegate field configuration

Once you know you're going to onboard a corporate IT division to JSD, you always look for what Atlassian apps (add-ons) might be necessary. In this case, the requirements were clear. We needed apps for Jira Service Management to:

Delegate the administration of the service catalogue to the IT team without promoting them to Jira Admins
Create cascading fields with n levels.
Restrict the context of lower level fields with parent fields. As shown in the image below, developers need to have a limited choice that allows them to find exactly what they're looking for in no time:

Integrating Projectrak for Jira and Elements Connect to build the ITSM catalog in Jira Service Management

After studying several alternatives, we decided that the best choice was the combination of Elements Connect (formerly nFeed) and Projectrak for Jira, that the customer was already using as a key component for their PPM framework in Jira Software. Together, they covered all our requirements:

Projectrak fields can be edited and created by project administrators, allowing experts that were closer to the actual catalogue maintenance to do the work.
With Projectrak, fields can have children fields with any number of levels. Simply, as many as you need!
With Connect, Projectrak project custom fields can be placed virtually anywhere in Jira Service Management (previously Jira Service Management).
Although both tools have well-document APIs, there's an existing integration that makes it super simple to combine the above benefits.

Integrate Profields for Jira and Elements Connect with Jira Service Desk

Minimizing custom fields in the catalog

With this solution, we only need one Projectrak's project custom fields and one custom field for each level of the catalog.

With other tools mentioned, the number is exponentially higher. For example, let's imagine that we have offices accross a lot of cities and we want people to choose the city. If we followed all the conections in this image we would end up with at least 16 custom fields.

Projects fields showed by the integrations with Profields and Connect

With Projectrak and Elements Connect, only 3 project fields and 3 custom fields are needed. That's less than one third than in the previous option!

Connecting Profields and Elements Connect makes work easier

Basic configuration of Projectrak + Elements Connect to capture a multilevel IT service catalog

Let's see a quick example of how to set up a comprehensive IT Service catalog in Jira Service Management using the integration of Projectrak and Connect.

Creating the fields in Projectrak

In the Projectrak tab, go to "Fields" and create a new list field. When you're given the option, choose "single choice".
Name it properly, like IT Service catalog (1st level). This seems obvious, but remember that naming conventions are super important!
Enter all the options in that level, and save the field
Create a new list field for the next level.
Before typing any options, go to the three-dotted button in the top right corner of the modal window, and select "Depends on another list"; then select the parent field
Now you can fill in the corresponding children that are possible for each parent value
Repeat 4-6 until the final level is complete.

Why is this step important?

When this step has been finalized, the entire service catalog is captured in only five custom fields (or as many as the total levels of complexity in the catalog tree). But we still can't use the options in JSD because what we just defined is project metadata.

Note how simple this configuration is. Anybody can do it: in fact, the creation and maintenance of the fields is not only permitted to project admins (or anybody else who has been appointed as Projectrak Admin) -- it is also transparent to them from the first moment, since no technical skills are required, and no additional database is needed to store the values.

Setting the logic in Elements Connect

In order to apply this field structure to Jira Service Management tickets, we'll need to move over to Connect and tell the tool how to read what we just did -- In the end, these are still five separate project fields, so we have to train Connect to read them as levels of a unitarian catalog on order to load them in Jira custom fields. Only then will the developers be able to request a new repository through the customer portal with a couple of clicks.

Below is an example of how to read Projectrak values through the Rest API to populate the options of each custom field. You can check the Elements Connect documentation for more info on the setup.

How to read Profields values through the Rest API to populate the options of each custom field

What does the result look like on the Customer Portal?

As a result, we obtain multi-level dynamic dropdowns both in Jira and in the Service Management portal. As an example, this is what it will look like with the 4th-level example of Planets > Continents > Countries > Cities.

Conclusion: Empowering project admins

When dealing with an unlimited license of Jira that is going to be deployed with the goal of servicing thousands of users with hundreds of agents around the globe, every small detail counts. Every custom field will impact performance (remember they probably have hundreds of them already!) so often it's vital to stick to a bare minimum. Instead of stripping off the service catalog of all the options that had been designed to ensure that the context for each request was properly captured so that back and forth communication and clarifications could be eliminated (or almost so), we were able to preserve the original catalog while adding only one custom field for each level of the catalog.

More importantly, the catalog had to be maintained by IT employees without the Jira Admin role. Giving them permission as project admins, they could edit the catalog in Projectrak. The setup requires only an initial configuration by a systems administrator – the dependencies and options can be delegated.

While it may seem counterintuitive to integrate two apps for the catalog, we consider it an important success: we managed to adapt the tool to the intended use, and not the other way around. And that's what counts for our customers.

Projectrak (previously Profields) and Elements Connect are available at the Atlassian Marketplace. Customers of all Jira Server & Data Center products can benefit from the integration between both apps.