So findet ihr Jira-Automation-Regeln, die Vorgänge in anderen Projekten erstellen
Eine Regel (Flow) eines Teams erstellt Vorgänge in einem Projekt (Bereich), das jemand anderem gehört. Das empfangende Team erfährt es meist aus den Tickets.
Auf jeder großen Jira-Instanz gibt es dieses Gespräch: „wer erstellt ständig diese Tickets in unserem Backlog?" Niemand aus dem Team war es. Eine Regel war es — eine Regel, die in einem anderen Projekt lebt, von einem anderen Team geschrieben wurde, und an deren Existenz sich auf keiner Seite jemand erinnert.
Auf einer realen Jira-Cloud-Instanz mit 1 214 Regeln in 98 Projekten sind 95 Regeln (Flows) so konfiguriert, dass sie Vorgänge außerhalb ihres eigenen Geltungsbereichs erstellen — 184 Verbindungen insgesamt, deaktivierte Regeln eingeschlossen. Das ist kein Fehler; ein Service Desk, der ein Entwicklungsticket öffnet, tut genau das Richtige. Das Problem ist, dass das empfangende Team es nicht sehen kann.
Warum es vom Empfänger aus unsichtbar ist
Jiras Regelliste ist danach geschnitten, wo eine Regel lebt, nicht wo sie wirkt. Öffnet ihr die Automation-Einstellungen von Projekt B, seht ihr die Regeln von Projekt B. Eine Regel aus Projekt A, die Vorgänge in B erstellt, taucht in dieser Liste nirgends auf — es sei denn, der Geltungsbereich der Regel schließt B ein.
Das Team, das die Tickets bekommt, kann also nicht aufzählen, was in seinem Projekt Vorgänge erstellt — und das Team, dem die Regel gehört, hat keinen Anlass, daran zu denken. Die Abhängigkeit ist real, tragend und undokumentiert.
Wählt einen Bereich, und die Regeln anderer Bereiche, die darin Vorgänge erstellen, hängen an seinem grünen Knoten
Die drei Formen
Vorgänge erstellen. Die sichtbarste — Arbeit erscheint von außen in einem Backlog. Meist gewollt, gelegentlich eine Schleife, die niemand bemerkt, bis das Sprintboard voll ist.
Felder setzen. Eine Regel greift in die Vorgänge eines anderen Projekts und schreibt ein Feld. Hat dieses Feld im empfangenden Projekt ebenfalls einen Eigentümer, habt ihr zwei Schreiber, und keines der Teams weiß vom anderen. Das ist die Variante, die „der Wert springt immer zurück" erzeugt.
Vorgänge überführen. Eine Regel bewegt Arbeit durch den Workflow eines anderen. Die Kennzahlen des empfangenden Teams verändern ihre Form, und niemand kann erklären, warum.
Automation Map listet die erste Form — jede Regel, die Vorgänge außerhalb ihres eigenen Geltungsbereichs erstellt. Feldänderungen und Statusübergänge in einen anderen Bereich (Projekt) hinein werden nicht gelistet; für ein Feld fragt den Rovo-Agenten „wer fasst dieses Feld an".
Warum das wichtiger ist als früher
Drei Gründe, einer davon neu:
- Teamgrenzen. Projektübergreifende Regeln sind der Weg, auf dem die Automatisierung eines Teams zum Incident eines anderen wird. Sie auflisten zu können ist der Unterschied zwischen einer Governance-Richtlinie und einem Wunsch.
- Berechtigungen. Eine Regel läuft unter einem Konto. Hat dieses Konto projektübergreifende Rechte, erbt die Regel sie. Regeln, die in Projekten Vorgänge erstellen, an die ihr eigenes Team sonst nicht herankommt, verdienen eine eigene Prüfung.
- Kosten. Ab Dezember 2026 wird jeder Schritt abgerechnet — auch die der Regeln im empfangenden Bereich, die auf das reagieren, was die sendende Regel erstellt hat, sofern sie Flow-Trigger zulassen. Eine projektübergreifende Regel kann der Anfang einer Kette sein, die niemand je von Anfang bis Ende gesehen hat.
Wie ihr die Liste bekommt
- Regeln exportieren: Jira-Einstellungen → System → Automation flows → More actions (…) → Export flows (Export rules auf älteren Instanzen).
- Die Datei in Automation Map laden.
- Euren Bereich (Projekt) auf der Karte wählen. Regeln aus anderen Bereichen, die darin Vorgänge erstellen, hängen an seinem grünen Knoten; ein Klick auf den Knoten zeigt die Liste.
- Um alles zu sehen, was zwischen zwei Teams die Grenze überquert, wählt den zweiten Bereich unter links with another project….
HINWEIS: Die Karte zeigt, was die Konfiguration erlaubt. Wie oft eine Regel lief, steht in Jiras Performance insights; was ein Lauf getan hat, im Audit-Log (90 Tage). Die App liest keines von beiden.
FAQ
Wie finde ich Regeln, die Vorgänge in einem anderen Jira-Projekt erstellen?
Exportiert eure Automation-Regeln und schaut, wo jede Regel Vorgänge erstellt statt wo sie liegt. Automation Map hängt diese Regeln an den Knoten des empfangenden Projekts auf der Karte, mit der Liste dahinter.
Warum sehe ich fremde Regeln nicht in den Automation-Einstellungen meines Projekts?
Weil Jira die Regelliste nach Zugehörigkeit schneidet, nicht nach Wirkung. Eine Regel aus Projekt A, die Vorgänge in B erstellt, steht nur unter A.
Ist eine projektübergreifende Regel (ein Flow) ein Problem?
Meist nicht — viele davon sind gewollte Integrationen zwischen Teams. Das Problem ist, dass das empfangende Team sie nicht aufzählen kann, also prüft sie niemand und niemand weiß, was kaputtginge.
Was hat das mit Berechtigungen zu tun?
Eine Regel handelt unter einem Konto und erbt dessen Rechte. Eine Regel, die in Projekten Vorgänge erstellt, die ihr eigenes Team manuell nicht erreicht, verdient einen eigenen Blick — die Automatisierung ist das Einzige, was diese Reichweite gewährt.
Kostet das unter der Schritt-Abrechnung mehr?
Es kann. Ein von außen erstellter Vorgang ist ein Ereignis im empfangenden Projekt, das dort Regeln wecken kann, sofern sie Flow-Trigger zulassen. Auch diese Schritte werden abgerechnet, und die Kette überquert eine Teamgrenze, an der niemand das Ganze im Blick hat.
Sehe ich, wie viele Vorgänge eine Regel erstellt hat?
Nicht von außerhalb Jiras. Laufzahlen stehen in Jiras Performance insights und im Audit-Log, für die es keine öffentliche API gibt. Struktur ist exakt, Mengen sind Jiras Sache.
Findet heraus, wer in eurem Backlog Vorgänge erstellt
Die Regeln, die eure Projektgrenze überqueren, existieren bereits. Die einzige Frage ist, ob ihr eine Liste davon habt.
👉 Automation Map für Jira — seht, welche Bereiche Vorgänge in eurem erstellen