Conditional Field Requirements in Jira Cloud ScriptRunner Behaviors

Other Questions Jira
1

I need assistance with establishing conditional field validation using ScriptRunner Behaviors in Jira Cloud. My aim is to make specific fields mandatory depending on the selection from another field.

Specifically, when a user selects ‘iOS’ from the ‘Operating System’ dropdown, I want the ‘iOS Build Number’ field to be required. Conversely, if ‘Android’ is chosen, the ‘Android Build Number’ field should also become mandatory.

Here’s the Groovy script I created for the Behavior validator:

def currentIssue = issue
def osFieldName = "Operating System"
def iosBuildFieldName = "iOS Build Number"
def androidBuildFieldName = "Android Build Number"
def selectedOS = currentIssue.fields[osFieldName]?.value?.toString()
def iosBuildValue = currentIssue.fields[iosBuildFieldName]?.value
def androidBuildValue = currentIssue.fields[androidBuildFieldName]?.value

if (selectedOS) {
    if (selectedOS == "iOS" && !iosBuildValue) {
       return false, "iOS Build Number must be filled when iOS is selected."
    }
if (selectedOS == "Android" && !androidBuildValue) {
    return false, "Android Build Number is required for Android platform."
    }
}
return true

I’m curious if this method is appropriate for Jira Cloud with ScriptRunner Behaviors. Should I have concerns over any edge cases or performance aspects? Would utilizing workflow validators be more effective for this scenario?

Any guidance or examples would be greatly appreciated. Thanks!

2

Hit the same issue last year with mobile workflows. Behaviors are the right approach, but Cloud has a nasty gotcha with field access that caught me off guard. Don’t use currentIssue.fields - work directly with field objects in the Behavior context instead. The issue object isn’t fully loaded during Behavior execution like it is on Server. One thing to watch: when users flip between iOS and Android repeatedly, clear validation errors from the old build number field. I added logic to reset error states whenever the OS selection changes - saves users from getting confused. Performance isn’t an issue since Behaviors run client-side, but test different field setups thoroughly. Custom field IDs change between instances and can break things.

3

You’re on the right track with ScriptRunner Behaviors - I’ve used this approach on several projects. Behaviors beat workflow validators for this stuff because users get instant feedback instead of hitting errors after trying to transition. But there’s a problem with how you’re referencing fields. Don’t use issue.fields directly in Behaviors - it won’t work reliably. Use getFieldByName() or getFieldById() instead:

def osField = getFieldByName("Operating System")
def iosBuildField = getFieldByName("iOS Build Number")
def selectedOS = osField.getValue()

if (selectedOS?.toString() == "iOS" && !iosBuildField.getValue()) {
    iosBuildField.setError("iOS Build Number is required when iOS is selected")
}

Make sure you set the Behavior to trigger when the Operating System field changes. Performance won’t be an issue with simple validation like this. Workflow validators would just overcomplicate things and annoy users.

4

your logic looks solid, but add null checks for edge cases. watch out for field initialization - behaviors sometimes fire before fields load, causing weird results. I’ve seen dropdown comparisons fail because of whitespace or casing, so use .trim().toLowerCase() when comparing values. behaviors beat workflow validators for real-time validation like this.