image
See how Jira and Innovalog's workflow automation can help
2 minutes reading time (489 words)

How to prevent a user from choosing an inapplicable support type

Prevent a user from choosing an inapplicable support type

 ​This solution was provided by Darryl Lee. It has earned a $100 donation to FIRST. Challenge was submitted by Rachel Wright.

Challenge:

A customer submits a support request through the Jira Service Management customer portal. A help desk technician receives the request and classifies it by choosing a Component representing an impacted software application or business area. They use a second field to select the type of support needed. 

The type of support available needs to be Component-specific. For example, if the Component is "email," the only applicable support selections are "troubleshooting" and "monitoring." If the Component is "network," the only suitable support selections are "monitoring" and "security."

Solution:

Using JMWE's "Build-your-own (scripted) Validator" you can customize your workflow to prevent a user from choosing an inapplicable support type for the selected Component.​

General setup:

  • Modify the default "Problem Management workflow for Jira Service Management" workflow in the default HELP project in Jira Cloud.
  • For simplicity, make the Component required via field configuration.
  • The Components and Support fields should only be visible in View and not Edit screens. However, if you use JMWE's new Event-based Action to validate changes during Edit, you can set that up as well (not covered in this example).
  • Added Components and Support fields to the transitions Review and Investigate will allow us to validate those fields when the issue is triaged, or work begins.


JMWE solution:

The Build-your-own (scripted) Validator allows you to check different combinations of Components and Support field options. Here is the Jira Expression that was used (where the Support field is customfield_10074):

  • First, we check to make sure the Support field is populated.
  • As "Monitoring" is valid for any component that stands alone.
  • We then only allow "Troubleshooting" if the Component is "Email".
  • Finally, we only allow "Security" if the Component is "Network".

Other conditions can be added as needed. If any of the conditions fail, we display an error message listing each Component's valid options.


Note about Components:

This challenge would seem to imply that only one Component can be selected at a time. Unfortunately, the built-in "Field has single value Validator" suffers from the same problem as other validators. When the validators fail in the Customer Portal, users get a generic error due to JSDCLOUD-5853. We could help customers by adding a description below the Components field that says, "Only one Component allowed. Otherwise, you will receive a generic error."​


If we were on Jira Server or Jira Data Center, this could be mitigated with a velocity template hack. (
JRASERVER-12543)


Note about the UX (don't surprise the user):

While this was a fun exercise, it elides an important fact: this is bad UX. Putting up an error message about selecting what looks like a viable option violates the principle of least surprise. 

A better option is a Message Custom Field that lists the allowed options per Component:

Jira Cloud Standard vs. Premium vs. Enterprise - w...
Perform on-the-fly calculations with JMWE for Jira...

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Saturday, 18 September 2021

Captcha Image