This solution was provided by Darryl Lee. It has earned a $100 donation to FIRST. Challenge was submitted by Rachel Wright.
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."
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.
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):
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: