Warum Behaviours in Jira Cloud ohne Entwickler auskommen sollten

Warum Behaviours wichtig sind

Mit einem großen europäischen Telekommunikationsanbieter haben wir komplexe Geschäftsprozesse in Jira modelliert — Projektmanagement, Kapazitätsmanagement, Budgetmanagement und Buchhaltung. Eine Erkenntnis kam immer wieder: Ohne bedingte Validierungen und dynamisches Verhalten der Eingabemasken lassen sich diese Prozesse in Jira nicht mit der Genauigkeit abbilden, die das Business erwartet.

Die Daten bleiben außerdem nicht in Jira. Sie fließen in Datenbanken, SAP und Power-BI-Berichte, auf denen echte Governance- und Finanzentscheidungen beruhen. Ein leeres Pflichtfeld oder eine irrelevante Option auf dem falschen Screen ist kein Hygienethema — der Fehler pflanzt sich durch die gesamte Reporting-Kette fort.

Ein konkretes Beispiel: Ein Anwender erfasst Kostenschätzungen über mehrere Geschäftsjahre. Werden die Jahre in falscher Reihenfolge oder mit falschen Referenzen eingegeben, bleibt der Fehler nicht in Jira. Er landet in der Datenbank, wird über die Synchronisation nach SAP übertragen, und plötzlich muss derselbe Fehler an drei Stellen korrigiert werden statt an einer. Ein Behaviour hätte ihn direkt an der Eingabe abgefangen.

Behaviours lösen das am Eintrittspunkt, nicht im Nachgang. Anwender sehen nur die Felder, die für ihren Fall relevant sind. Pflichtfelder sind nur dann Pflicht, wenn sie es wirklich sein sollen. Irrelevante Felder verschwinden. Das Ergebnis: weniger Reibung für den Anwender, höhere Datenqualität an der Quelle.

Die Migrationsherausforderung von Jira Data Center

Viele unserer Enterprise-Kunden — und unzählige Teams im gesamten Ökosystem — migrieren von Jira Data Center nach Jira Cloud. Behaviours gehören zu den ersten Dingen, die dabei brechen.

In Jira Data Center sind gescriptete Behaviours typischerweise in Groovy geschrieben. In Jira Cloud gibt es diese Laufzeitumgebung nicht mehr. Die Skriptsprache ist eine andere, die Architektur ist eine andere, und über Jahre gewachsene Behaviour-Logik müsste theoretisch von Entwicklern neu gebaut werden.

Die eigentliche Frage ist also nicht, wie man die Skripte portiert. Die Frage ist, ob eine Cloud-Migration nicht der richtige Moment ist, um das Developer-in-the-Loop-Modell hinter sich zu lassen — und auf eine Konfiguration umzusteigen, die ein Jira-Administrator selbst besitzen kann, ohne eine einzige Codezeile.

Die Plattform-Herausforderung in Jira Cloud

Auch nativ in Jira Cloud bringen Behaviours eigene Herausforderungen mit. Der unterste Baustein von Atlassian ist die UI Modifications API — und diese Ebene entwickelt sich noch. Die Abdeckung ist ungleichmäßig: Für Jira Service Management ist die Unterstützung aktuell in Preview, und was möglich ist, hängt vom Bereich und Vorgangstyp ab. So entsteht ein Flickenteppich — in einem Kontext funktioniert etwas, im anderen nicht.

Für einen Jira-Administrator wird daraus die Frage: Muss ich wirklich selbst im Blick behalten, was eligible ist und was nicht? Behaviours, die zur Laufzeit stillschweigend fehlschlagen, sind die schlechteste Art des Scheiterns. Die Validierung muss am Konfigurationseingang passieren — nicht erst, wenn ein Endanwender auf Speichern klickt.

Jede Schicht, die auf UI Modifications aufsetzt — ob No-Code-Konfigurator oder script-basiertes Behaviour-Produkt — muss mit diesen Plattformänderungen Schritt halten. Idealerweise läuft diese Übersetzung als Service, sodass dem Administrator nur das angeboten wird, was tatsächlich unterstützt wird, und die darunterliegende Bewegung unsichtbar bleibt.

Woraus unsere Behaviour-App entstanden ist

Auf dem Atlassian Marketplace gibt es genug gute Behaviour-Apps — code-basiert wie No-Code. Fünf Anforderungen sind für uns zum Muss geworden:

1. Kontinuierliche Eligibility-Prüfung. Ein Administrator darf kein Behaviour konfigurieren können, das nicht laufen kann. Jede Kombination aus Bereich, Vorgangstyp, Screen und Feld muss zu etwas Ausführbarem auflösen — validiert während der Konfiguration, nicht erst zur Laufzeit.
2. Schnelle Adoption neuer Plattformfähigkeiten. Die UI Modifications API bewegt sich ständig. Wenn Atlassian Unterstützung für neue Felder oder Screens ergänzt, sollten Admins nicht erst auf ein App-Release warten müssen, um sie zu nutzen — die Übersetzung sollte über einen schnellen internen Prozess laufen.
3. Projekt- und vorgangstypenübergreifende Behaviours, einmal definiert. Ein Behaviour, das sich über mehrere Bereiche und Vorgangstypen erstreckt, sollte nur einmal definiert werden — die Eligibility-Prüfung berechnet den gemeinsamen Nenner über den gesamten Scope.
4. Die Lücke zum Scripting schließen. Skriptsprachen bieten immer die größte Flexibilität. Ziel ist, diese Lücke zu verkleinern: unbegrenzte Kombinationen von Bedingungen, Bedingungen jenseits dessen, was UI Modifications nativ erlaubt (z.B. Links und Permissions), und Werte, die dynamisch aus anderen Feldern oder dem Kontext abgeleitet werden.
5. Wiederverwendbare Konfigurationsbausteine. Wenn eine Bedingung wie „Priorität ist Medium oder Highest“ in vielen Behaviours vorkommt, sollte sie an einer Stelle leben und referenziert werden — nicht dupliziert. Die App sollte so funktionieren, wie Jira selbst funktioniert: Artefakte sind verbunden, Redundanz verschwindet, Wiederverwendbarkeit steht an erster Stelle.

Der VIP.LEAN Behaviours Builder im Überblick

Der VIP.LEAN Behaviours Builder ist entlang von vier praktischen Fragen aufgebaut:

1. In welchem Kontext? → Behaviours halten den Scope: für welche Bereiche und Vorgangstypen die Logik greift.
2. Was soll modifiziert werden? → Actions liegen innerhalb der Behaviours. Jede Action adressiert ein Feld und kann — abhängig von Scope und Feld — auf mehreren Screens gleichzeitig wirken (Create, View, Transition) — nicht nur auf einem.
3. Wann soll modifiziert werden? → Bedingungen werden zentral definiert, sind wiederverwendbar und lassen sich mit einfachen Operatoren (UND, ODER, NICHT) oder fortgeschrittenen Ausdrücken kombinieren. Sie prüfen Felder, Links und Permissions — und gehen damit über das hinaus, was UI Modifications nativ bietet. Relative und kontextbasierte Bedingungen (heute, gestern, Rolle des aktuellen Benutzers) stehen auf der Roadmap.
4. Wie soll modifiziert werden? → Field Modifications — wir haben bereits den vollständigen Satz an Feldmodifikationen implementiert, den Atlassian derzeit über die UI Modifications API bereitstellt: Anzeigen/Ausblenden, Pflicht/Optional, Schreibgeschützt/Editierbar, Label, Description, Wert setzen und Wert ableiten.
   
   

Ein paar Beispiele aus der Konfigurationsoberfläche:

[Behaviour-Liste — Übersicht der konfigurierten Behaviours über Bereiche und Vorgangstypen hinweg]

[Action mit mehreren kombinierten Bedingungen]

[Set-Value-Action mit Rich-Text-Editor]

Selbst ausprobieren:

• Produktseite
• Interaktiver Walkthrough: Quick Tour
• Auf Jira Cloud installieren: Atlassian Marketplace

Wie geht es weiter?

1. Use Cases aus der Praxis, genau hier. Wir werden weiterhin Beiträge zu Use Cases veröffentlichen — kaskadierende Felder, Optionsfilterung nach Projekt und Vorgangstyp und mehr. Wenn Sie einen konkreten Bedarf oder eine Idee haben, die wir aufgreifen sollen, sagen Sie uns Bescheid — wir nehmen sie auf.
2. Die Lücke zum Scripting schließen. Parallel dazu verkleinern wir den Abstand zwischen No-Code und Code — mit Kontextvariablen, dynamischen Werten und weiteren Stellen, an denen Scripting bisher die einzige Antwort war.
3. Atlassian im Blick. Die vielversprechendste Entwicklung auf unserem Radar ist die Unterstützung von UI Modifications für Jira Service Management — aktuell noch in Preview. Sie steht auf unserer Roadmap, und wir arbeiten bereits daran.

‍