Let’s consider the need:
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.”
Here is the 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 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.
Using Jira Misc Workflow Extensions (JMWE):
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:
Last updated: 2023-07-31
Appfire
Appfire is an enterprise collaboration software company that enables teams to plan and deliver their best work. Since launching in 2005 as one of the original Atlassian ecosystem partners, Appfire has built a portfolio of top-selling apps for more than 30,000 customers — including 55% of Fortune 500 companies. As a product-led company, Appfire identifies gaps in industries serving developers and client support teams and then builds solutions that drive productivity and efficiency.
See all content by Appfire
