So seht ihr, was von einer Jira-Automation-Regel abhängt, bevor ihr sie abschaltet
Jira zeigt eine Regel (Flow) für sich allein. Was von ihr abhängt, zeigt es nie. So seht ihr ein- und ausgehende Ketten, bevor ihr den Schalter anfasst.
Die Frage kommt jedes Mal auf, wenn jemand die Regelliste öffnet: die sieht überflüssig aus — was geht kaputt, wenn ich sie abschalte? Niemand kann es beantworten, also bleibt die Regel an, und die Liste wächst ein weiteres Jahr.
Der Grund ist strukturell. Jiras Regel-(Flow-)Editor zeigt eine Regel nach der anderen. Er hat keine Sicht darauf, was nach den Aktionen dieser Regel passiert — welche anderen Regeln aufwachen, weil diese einen Vorgang bearbeitet, überführt oder erstellt hat. Diese Beziehung steckt in den Daten und wird nirgends gezeigt.
Zwei Richtungen, zwei verschiedene Risiken
Ausgehend. Die Aktionen dieser Regel erzeugen Ereignisse. Andere Regeln triggern darauf. Schaltet ihr sie ab, hören die auf zu feuern, für die Ereignisse, die diese Regel auslöste — lautlos, denn eine Regel, die einfach nie läuft, meldet nichts.
Eingehend. Andere Regeln erzeugen die Ereignisse, auf die diese reagiert. Schaltet jemand eine davon ab, bekommt diese Regel diese Ereignisse nicht mehr. Das ist derselbe Fehler vom anderen Ende gesehen — und die häufigere Überraschung: mit der Regel, auf die alle starrten, war alles in Ordnung.
Beide Richtungen müssen sichtbar sein, bevor der Schalter sicher ist.
Ein- und ausgehende Ketten einer Regel
Der Schalter, der über die Existenz einer Kette entscheidet
Eine Kette von Regel A zu Regel B funktioniert nur, wenn bei B Allow flow trigger (Allow rule trigger auf älteren Instanzen) eingeschaltet ist. Diese Einstellung steckt in Bs eigenen Einstellungen — und sie ist standardmäßig aus.
Es ist eine der folgenreichsten Einstellungen in Jira Automation, und sie erzeugt zwei gegensätzliche Fehler:
- Eine Kette, die ihr für vorhanden haltet, die es aber nicht gibt. A feuert, B sollte folgen, bei B war der Schalter nie an. Nichts meldet einen Fehler.
- Eine Kette, die ihr vergessen habt. Bei B ist der Schalter an, also stoppt das Abschalten von A still und leise B, drei Teams weiter.
Auf einer realen Instanz würden 1 724 Regelpaare verkettet laufen, wenn die empfangende Regel es zuließe — die meisten waren nie so gemeint. Welche doch, lässt sich aus Jira heraus nicht sagen. Auf derselben Instanz feuern 293 Ketten tatsächlich. Die nützliche Zahl ist keine der Summen, sondern welche davon die Regel vor euch berühren.
Ringe
Ketten können sich schließen. Regel A bearbeitet einen Vorgang, das weckt Regel B, die ihn überführt, was wieder A weckt. Auf einer realen Instanz gibt es 25 solcher Rekursionen — 21 Regeln, die sich selbst auslösen, und 4 Ringe über mehrere Regeln.
Jira hat eine Schleifenbremse, also laufen die meist nicht davon. Aber jeder Durchlauf wird unter der Schritt-Abrechnung ab Dezember 2026 berechnet, und ein Ring ist beim Lesen einzelner Regeln praktisch nicht zu finden — man muss alle gleichzeitig ansehen.
Wie ihr vor dem Umschalten prüft
- Regeln exportieren: Jira-Einstellungen → System → Automation flows → More actions (…) → Export flows (Export rules auf älteren Instanzen).
- Die Datei in Automation Map laden.
- Die Regel öffnen, die ihr abschalten wollt, und ihren Links-Tab lesen: welche Regeln sie auslösen, welche sie selbst auslöst — und welche dieser Verbindungen der
Allow flow trigger-Schalter blockiert. - Ketten einen Schritt weiter verfolgen, falls stromabwärts etwas tragend aussieht.
- Oder fragt den Rovo-Agenten „was stoppt, wenn ich diese Regel abschalte?" — er listet nur die Verbindungen, die tatsächlich feuern, in jeder Edition.
HINWEIS: Die Karte zeigt, was die Konfiguration möglich macht. Wie oft eine Kette tatsächlich feuert, kann sie nicht sagen: das steht in Jiras Performance insights, und was ein Lauf getan hat, im Audit-Log, 90 Tage lang. Die App liest keines von beiden.
FAQ
Wie erfahre ich, was von einer Jira-Automation-Regel abhängt?
Ihr braucht die ein- und ausgehenden Verknüpfungen — welche Regeln sie auslösen und welche ihre Aktionen wecken. Jiras Editor zeigt beides nicht; Automation Map baut beide Richtungen aus der exportierten Konfiguration.
Was ist die Einstellung „Allow flow trigger"?
Ein Schalter in den Einstellungen eines Flows (Allow rule trigger auf älteren Instanzen), der entscheidet, ob sie von den Aktionen anderer Regeln ausgelöst werden darf. Er ist standardmäßig aus — deshalb existieren viele Ketten nicht, an die alle glauben.
Warum hörte meine Regel auf, als ein Kollege eine andere abschaltete?
Vermutlich, weil eure stromabwärts lag: Die abgeschaltete Regel erzeugte das Ereignis, auf das eure triggerte, und eure ließ Flow-Trigger zu. In diesem Fall meldet nichts einen Fehler — die Regel bekommt dieses Ereignis einfach nicht mehr, was monatelang unbemerkt bleiben kann.
Sind 1 724 blockierte Paare ein Problem?
An sich nicht. Die meisten Regeln sollten nie verkettet werden, und der ausgeschaltete Schalter ist für sie richtig. Das Problem ist, dass ihr aus Jira heraus nicht erkennen könnt, welche davon jemand als lebendig gemeint hat.
Wie finde ich rekursive Automation-Regeln?
Eine Rekursion ist ein Zyklus im Trigger-Graphen — eine Regel, die sich am Ende selbst wieder auslöst. Sie zu finden heißt, alle Regeln gleichzeitig anzusehen; einzelnes Lesen bringt sie nicht ans Licht.
Sehe ich, wie oft eine Kette wirklich feuert?
Nicht auf der Karte. Wie oft eine Kette feuert, steht in Jiras Performance insights, was ein Lauf getan hat, im Audit-Log (90 Tage); eine öffentliche API dafür gibt es nicht. Struktur ist exakt, Häufigkeit ist Jiras Sache.
Erst schauen, dann schalten
Eine Regel abzuschalten dauert einen Klick. Herauszufinden, was sie gefüttert hat, kann ein Quartal dauern — wenn die Antwort als Beschwerde eintrifft.