How to Configure Jira Field Behaviours Without Writing a Single Line of Script

[#1]

If you have ever maintained ScriptRunner behaviours, Groovy validators, or custom JS listeners in Jira Cloud, you already know the problem.

The script works on day one. Then someone adds a field. Then someone changes the workflow. Then a new issue type shows up in the same project. Six months later, nobody on the team wants to touch that 200-line Groovy file.

The logic is usually not that complicated. What makes it fragile is the delivery vehicle: a tightly coupled script where field IDs, conditional branches, and value mappings all live in one block of code that only the original author fully understands.

What if field behaviour worked like Jira Automation?

Most Jira admins already know how to use Jira Automation. You pick a trigger, add conditions, define branches with IF/ELSE logic, and attach actions at each branch. No code required. The whole rule is visible as a flow you can walk through and explain to someone else.

That same model works for field behaviour — and Auto Behaviour applies it directly to Jira fields. Instead of writing a script that says "if priority is highest, make Impact required and visible," you build a visual rule:

1. Pick a trigger — which field change should kick off the rule.
2. Add conditions — what must be true for the rule to apply.
3. Define IF/ELSE branches — different paths for different contexts.
4. Attach actions — show, hide, require, lock, or set values on target fields.

The rule is a flow. Not a script.

A concrete example: incident intake without scripts

Consider a common scenario. A software operations team wants the issue create form to stay short for normal tickets, but when the reporter selects a high-severity incident type, the form should immediately:

• Show and require `Impact`
• Show and require `Affected Service`
• Show `Incident Commander` and `Root Cause Category`

Here is what that looks like as a visual rule in Auto Behaviour:

• Trigger: `Priority` field — both on load and on change.
• Condition: `Priority = Highest`.
• IF branch (match):
  • `Impact` → visible, required
  • `Affected Service` → visible, required
  • `Incident Commander` → visible
  • `Root Cause Category` → visible
• ELSE branch (fallback):
  • `Impact` → hidden
  • `Affected Service` → hidden
  • `Incident Commander` → hidden
  • `Root Cause Category` → hidden

Every branch is explicit. Every target field has a defined state in every path. There is no hidden else clause. There is no field that "should probably be hidden too" but nobody remembered to add.

That is the design discipline Auto Behaviour's visual model enforces.

Why "on load" matters, and why scripts often miss it

One of the most common failure patterns in scripted behaviour is this: the rule only runs when something changes.

In Jira Cloud, the create screen may already have values prefilled when it loads. The issue type might be pre-selected. A default priority might already be set. If the rule only reacts to user changes, those prefilled values never trigger the behaviour, and the form loads in the wrong state.

The fix is simple in a visual model: enable the trigger on both on load and on change. That means the rule runs once when the form renders — catching any prefilled values — and then again whenever the user edits a trigger field.

In Auto Behaviour, that is a toggle on the trigger configuration. In a script, it usually means adding a separate initialisation block, a separate event handler, and making sure they share the same logic. That is where mistakes accumulate.

Another example: locking execution fields to the right people

A delivery team wants only the assignee or users in a developer role to edit `Implementation Plan`, `Deployment Window`, and `Rollback Owner` — but only when the status is `In Progress`. Everyone else should still see those fields, but they should be read-only.

As a visual rule in Auto Behaviour:

• Scope: `IssueView` for the target project.
• Conditions:
  • `Status = In Progress`
  • AND current user is the assignee, or is in the `Developers` project role
• IF branch (match):
  • `Implementation Plan` → editable
  • `Deployment Window` → editable
  • `Rollback Owner` → editable
• ELSE branch (fallback):
  • `Implementation Plan` → visible, read-only
  • `Deployment Window` → visible, read-only
  • `Rollback Owner` → visible, read-only

The key design choice here is that the fallback does not hide the fields. Other users still see the execution context; they just cannot change it. That is a deliberate UX decision that is visible in the rule itself — not buried in a conditional check on line 47 of a script.

Routing values with lookup tables instead of nested IF

statements

When routing decisions depend on multiple fields — Region, Request Type, Business Unit — scripts tend to become deeply nested conditionals that are hard to read and harder to maintain.

Auto Behaviour handles this differently. Instead of nesting, you define a lookup table:

Region	Request Type	Business Unit	Assignment Queue
APAC	Access Request	Finance	FIN-APAC-ACCESS
EU	Laptop Request	HR	HR-EU-ENDUSER
US	Access Request	IT	IT-US-ACCESS
*	*	*	GENERAL-TRIAGE

The table is the rule. Adding a new combination means adding a row, not modifying nested code. The fallback row with wildcards catches anything not explicitly mapped. Anyone on the team can review the routing table and understand the logic in seconds.

The derived variable from that lookup table can then be used directly in a `setValue` action to write the result into a target field.

Expressions for calculations without JavaScript

Some field behaviour requires computation: totals, thresholds, risk scores. In a script-based world, that means embedding JavaScript math in a string and hoping the types are right.

In Auto Behaviour, a `Create Expression` action handles the same computation as a named formula:

• `subtotal = {{form.unitCost}} * {{form.quantity}}`

• `total = {{var.subtotal}} * 1.1`

• `approvalTier = {{var.total}} > 5000 ? 2 : 1

Each expression stores its result in a named variable. Subsequent expressions and actions can reference those variables. Guard conditions can wrap the calculation to handle empty or malformed inputs. The computation is isolated from the UI-state logic, so changing the formula does not risk breaking visibility or requiredness rules elsewhere in the same flow.

What this looks like compared to maintaining scripts

Concern	Script-based	Visual rule model
Understanding the logic	Read through code	Walk through the flow
Adding a new field to an existing rule	Find the right place in the code, add handling, test side effects	Add the field to the relevant branch, define its state in all paths
Explaining the rule to a new admin	Walk through the script line by line	Point at the flow diagram
Changing trigger behaviour	Edit event listeners, add or modify handlers	Toggle on load / on change on the trigger
Updating a routing mapping	Modify nested conditionals	Add or edit a row in the lookup table
Detecting a missing fallback	Audit the entire script	Look for branches without complete action coverage

The visual model does not make the underlying Jira constraints disappear. Field API differences between views, value ID versus label semantics, and multi-app conflict risks still exist regardless of how you configure the behaviour. But the visual model makes the design intent visible, reviewable, and explainable in a way that scripts typically do not.

What field behaviour should not replace

A quick note on scope. Field behaviour is strongest when it shapes the editing experience in real time — controlling what users see, what they must fill in, and what values the form suggests or locks.

It is not a replacement for:

- Security boundaries — hidden fields can still be submitted in manipulated requests.

- Workflow enforcement— if a field must be required before a transition, use a workflow validator.

- Permission schemes — if whole issue types should be restricted to certain users, use project permissions.

Field behaviour and those mechanisms should work together. Auto Behaviour just makes the field-behaviour layer easier to own.