You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We have been working with a lot of Jira Service Management clients and I have been thinking a lot lately about the right design strategy for managing Request Type to Issue Type mappings.
The problem that I want to explore and get feedback on is the proliferation of fields on the Issue screens when we try to use a single Issue Type to support multiple Request Types.
Service Requests are the most common area where we see this problem. Let us assume for the sake of this discussion that I use a single Issue Type and Workflow for Service Requests. JSM has given me the ability to split this into many different request types for the benefit of my customer. I can have request types that span Hardware, Software, Network, Security, etc. Each Request Type can have its own set of fields that are specific an appropriate to that request, making it easier to get the right data for the ticket from the customer.
The result is that my Service Request screen starts to grow to accommodate all of the different fields that might be used across any of these Request Types. When my Agent looks at the screen, they see a proliferation of fields that have no value to the specific request being worked. This is especially problematic in Data Center where to edit an empty field, the Agent brings up an Edit screen that may have a list of 30 or more fields, many of which have no value to the specific request being worked.
One approach is to rely heavily on tabs to separate the fields into categories. This reduces the screen clutter. However, figuring out the right categorization for the tabs can be very tricky. Another downside is that the agent now has to click through various tabs to see or edit values. Tabs are great but they reduce the ability of the agent to quickly look at a ticket and see the information that they need to work the ticket.
Another approach is to divide the Service Request Issue Type into several Issue Types (e.g., Software Request, Hardware Request, etc) to allow each screen to be more streamlined. This starts to proliferate Issue Types and the associated Screen and Issue Type Screen schemes, which creates more administrative overhead to maintain.
A third approach that we have used is to make use of the Dynamic Forms and Extension for Jira Service Management plugins to show/hide fields based on the Request Type or some field in the issue itself. This is a very cool solution but it requires the purchase of two apps and creates an administration nightmare as well as having performance implications as the number of fields grows. I am a big fan of these two Deviniti apps (Disclosure: we are a Deviniti partner), however this use of the apps is, in my experience, exceed what they were intended to do.
Similarly, we could use ScriptRunner Behaviors to show/hide fields, but that suffers from the same administrative issues that the Deviniti apps create when overused for this purpose.
What are your approaches to handling this problem? Are there options that I have overlooked?