Equivalent JQL in Cloud for Scriptrunner "issuefunction in expression()"

Hi @Matt Parks,

There is no equivalent native Jira Cloud JQL for this comparison. Atlassian explicitly states that JQL cannot compare one field with another. The expression() function is provided by ScriptRunner on Data Center, so its availability in Cloud depends on the app rather than Jira’s native JQL.

A native Cloud workaround is to maintain a helper field with Automation:

• Create a checkbox or single-select field such as Estimate below Hours in Developing.
• Trigger the rule whenever Original estimate or Hours In Developing changes, and first confirm that both fields contain values.
• Use a smart-values condition with {{issue.timetracking.originalEstimateSeconds.divide(3600)}} on the left, less than as the operator, and {{issue.customfield_12345}} on the right. Replace 12345 with the ID of the Hours In Developing field.
• Set the helper field to Yes when the comparison is true and No otherwise.

You can then use normal JQL such as "Estimate below Hours in Developing" = Yes. Run the rule once on a schedule to populate existing work items, then let the field-change trigger maintain it. Atlassian documents the JQL field-comparison limitation and the available Automation comparison conditions.

Hola Matt,

There isn't a direct equivalent to ScriptRunner Data Center's expression() function in either native Jira Cloud JQL or ScriptRunner Enhanced Search for Cloud. Native JQL can compare a field with a fixed value or supported function, but it can't compare the value of one field directly with another.

The automation-based helper field already suggested is the most practical native Cloud approach. One refinement would be to use a numeric field, such as Estimate Variance Hours, instead of a Yes/No field. Automation could calculate Hours In Developing minus Original Estimate in hours, and you could then search with normal JQL, such as:

"Estimate Variance Hours"> 0

That also gives you the option to sort or report on the size of the variance rather than only identifying whether one exists.

The rule would need to run whenever either source field changes, and you'd need a one-time scheduled rule to populate the helper field for existing work items. I'd also add handling for cases where either field is empty, so stale values aren't left behind.

Atlassian confirms the field-to-field limitation here.

Thanks,

James