Why Behaviours in Jira Cloud Shouldn't Require a Developer

[#1]

Why behaviours matter

Working with a large European telecommunications operator, we've been modeling complex business processes in Jira — project management, capacity management, budget management, and accounting. What kept coming back was this: without conditional validations and dynamic screen behaviours, these processes simply can't be captured in Jira with the accuracy the business expects.

The data doesn't stay in Jira either. It flows into databases, SAP, and Power BI reports that drive real governance and financial decisions. A required field left blank or an irrelevant option shown on the wrong screen isn't a hygiene issue — it propagates all the way through the reporting chain.

To make this concrete: imagine a user entering cost estimates across several fiscal years. If those years are entered out of sequence or with the wrong references, the error doesn't stay in Jira. It gets exported to the database, pushed into SAP through the sync, and suddenly you're chasing the same fix in three places instead of one. A behaviour would have caught it at the front door.

Behaviours solve this at the point of entry, not afterwards. Users see only the fields that matter for their case. Required fields become required only when they actually should be. Irrelevant fields disappear. The result: less friction for the user, higher data quality at the source.

The migration challenge from Jira Data Center

Many of our Enterprise customers — and countless teams across the ecosystem — are migrating from Jira Data Center to Jira Cloud. Behaviours are among the first things that break.

In the Data Center, scripted behaviorus are typically written in Groovy. In Jira Cloud, that runtime is gone. The scripting language is different, the architecture is different, and years of accumulated behaviour logic would theoretically need to be re-engineered by developers.

So the question isn't how to port the scripts. It's whether a Cloud migration is the right moment to leave the developer-in-the-loop model behind — and move to a configuration that a Jira admin can own, without a single line of code.

The Jira Cloud platform challenge

Even in Jira Cloud natively, behaviours come with their own challenges. Atlassian's lowest-level building block is the UI Modifications API — and that layer is still evolving. Coverage is still uneven: Jira Service Management support is in preview, and what's possible varies by space type and work type. So you end up with a patchwork — something works in one context but not in another.

For a Jira administrator, the question becomes: Do I really need to track what's eligible and what isn't? Behaviours that silently fail at runtime are the worst kind of failure. Validation needs to happen at the configuration entry point — not when an end user hits Save.

Any layer built on top of UI Modifications — whether a no-code configurator or a scripted-behaviour product — has to keep pace with these platform changes. Ideally, that translation is handled as a service, so the administrator is only offered what's eligible and the underlying churn stays invisible.

Where our behaviour app was born

There's no shortage of smart behaviour apps on the Cloud marketplace — code-based and no-code alike. Five requirements became must-haves for us:

1. Continuous eligibility checking. An administrator must not be able to configure a behaviour that can't run. Every combination of space, work type, screen, and field has to resolve to something executable — validated during configuration, not at runtime.

2. Fast adoption of new platform capabilities. The UI Modifications API keeps moving. When Atlassian adds support for new fields or screens, admins shouldn't have to wait for an app release just to use them — the translation should happen through a fast internal process.

3. Cross-project, cross-work-type behaviours defined once. A behaviour that spans multiple spaces and work types should be defined once, with the eligibility check computing the common denominator across the entire scope.

4. Closing the gap to scripting. Scripting languages will always offer the most flexibility. The goal is to narrow that gap: unlimited combinations of conditions, conditions beyond what UI Modifications natively supports (e.g., links and permissions), and values derived dynamically from other fields or context.

5. Reusable configuration blocks. If a condition like "Priority is Medium or Highest" appears in many behaviors, it should live in one place and be referenced, not duplicated. The app should work the way Jira itself does: artefacts connect, redundancy disappears, reusability comes first.

Introducing VIP.LEAN Behaviours Builder

The VIP.LEAN Behaviours Builder is structured around four practical questions:

1. In which context? → Behaviours hold the scope: which spaces and work types the logic applies to.
2. What to modify? → Actions sit inside behaviours. Each action targets a field and, depending on scope and field, can apply across multiple screens (Create, View, Transition) — not just one.
3. When to modify? → Conditions are defined centrally, reusable, and can be combined with basic operators (AND, OR, NOT) or advanced expressions. They check fields, links, and permissions — going beyond what UI Modifications natively offers. Relative and context-based conditions (today, yesterday, current user's role) are on the roadmap.
4. How to modify? → Field Modifications — we've already implemented the full set of field modifications Atlassian currently exposes through the UI Modifications API: show/hide, required/optional, read-only/editable, label, description, set and derive values.
   
   

A few examples from the configuration UI:

[Behaviour list — overview of configured behaviours across spaces and work types]

[Action with multiple combined Conditions]

[Set Value action with rich-text editor]

Try it yourself:

• Interactive walkthrough: Quick Tour
• Install on Jira Cloud: Atlassian Marketplace

What's next?

1. Real-life use cases, right here. We'll keep publishing use-case posts in this community — cascading fields, option filtering by project and work type, and more. If you have a specific need or an idea you'd like us to cover, share it with us, and we'll pick it up.

2. Closing the gap to scripting. At the same time, we're narrowing the distance between no-code and code — adding context variables, dynamic values, and more corners where scripting used to be the only answer.

3. Watching Atlassian. The most promising development on our radar is UI Modifications support for Jira Service Management — currently still in Preview. It's on our roadmap, and we're already working on it.

---

A final word: If you have ideas for what Behaviours Builder should support within the scope of Atlassian's UI Modifications platform, let us know — we'd love to hear your feedback.