Jira Automation und Usage Based Pricing: Was sich ändert und was Unternehmen jetzt prüfen sollten

Atlassian stellt die Berechnung der Nutzung von Automatisierungen in der Cloud grundlegend um. Statt primär die Anzahl ausgeführter Automationsregeln zu betrachten, wird die Nutzung zukünftig anhand einzelner Automation Steps gemessen.

Die neuen Limits und die Abrechnung zusätzlicher Nutzung sollen ab dem 3. Dezember 2026 wirksam werden. Die entsprechende Usage-Auswertung stellt Atlassian bereits vorher zur Verfügung. Dadurch lässt sich heute prüfen, wie sich bestehende Automationen im neuen Modell verhalten würden.

Die Änderung sollte nicht ausschließlich unter dem Gesichtspunkt zusätzlicher Kosten betrachtet werden. Wenn das enthaltene Kontingent ausgeschöpft ist und keine zusätzliche Nutzung zur Verfügung steht, können die betroffenen Funktionen eingeschränkt werden. Bei Unternehmen, die Jira Automation für operative oder geschäftskritische Prozesse einsetzen, kann dies unmittelbare Auswirkungen auf die Verarbeitung von Vorgängen haben.

Auch kleine Jira-Umgebungen können davon betroffen sein. Entscheidend ist nicht primär die Anzahl der Benutzer oder Automationsregeln, sondern deren Aufbau und Ausführungshäufigkeit.

Vom Automation Run zum einzelnen Step

Bisher ließ sich die Nutzung relativ einfach über die Anzahl der Automation Runs beurteilen. Eine Regel wurde ausgelöst, führte mehrere Aktionen aus und wurde als entsprechende Ausführung in der Usage berücksichtigt.

Im neuen Modell betrachtet Atlassian die innerhalb eines Automation Flows tatsächlich ausgeführten Bestandteile.

Als Automation Steps zählen unter anderem:

• Trigger

• Conditions

• Actions

• Branches

• Loops

Werden Bestandteile innerhalb eines Branches mehrfach ausgeführt, steigt die Anzahl der Steps entsprechend.

Eine Regel mit folgendem Aufbau ist deshalb nicht einfach eine einzelne relevante Ausführung:

Scheduled Trigger
→ Assets Branch
    → REST Request
    → Assets Update
    → REST Request
    → Assets Update

Werden innerhalb des Branches beispielsweise 65 Assets-Objekte verarbeitet, werden die vier enthaltenen Aktionen für jedes dieser Objekte ausgeführt.

Vereinfacht ergibt sich:

1 Trigger
+ Branch
\+ 65 × 4 Aktionen

≈ 260 Automation Steps

Aus einer einzelnen Ausführung einer Regel können damit mehrere hundert relevante Steps entstehen.

Atlassian definiert einen Automation Step entsprechend als einen ausgeführten Bestandteil eines Automation Flows und nennt ausdrücklich Trigger, Conditions, Actions, Branches und Loops als relevante Bestandteile.

Ein konkretes Beispiel

Die Auswirkungen lassen sich an folgender Jira-Cloud-Umgebung gut nachvollziehen.

Nach dem bisherigen Usage-Modell ist die Umgebung hinsichtlich Automation vollkommen unauffällig. Im betrachteten Zeitraum wurden in Jira lediglich 342 von 10.000 verfügbaren Automation Runs verwendet.

Die Vorschau des neuen Modells zeigt dagegen bereits: 56.514 Automation Steps.

Die Analyse auf Ebene der einzelnen Regeln zeigt, dass die Nutzung keineswegs gleichmäßig verteilt ist.

Eine der Regeln weist lediglich 137 Flow Runs auf, verursacht dabei jedoch 35.620 Automation Steps.

Das entspricht durchschnittlich: 260 Steps pro Run.

Eine zweite Regel kommt bei 366 Flow Runs auf weitere 18.180 Steps.

Damit verursachen zwei Regeln zusammen 53.800 der insgesamt 56.514 Steps.

Das entspricht rund 95 Prozent der gesamten Automation-Nutzung.

Die Anzahl der Automationsregeln allein ist daher kaum geeignet, um die zukünftige Nutzung einzuschätzen.

Warum diese Regeln so viele Steps erzeugt

Der konkrete Aufbau der ersten Regel ist technisch relativ einfach.

Die Automation läuft zeitgesteuert und verarbeitet Projektobjekte aus Jira Assets.

Für jedes Projekt werden Daten über die Tempo REST API abgefragt und anschließend im entsprechenden Assets-Objekt gespeichert.

Der tatsächliche Aufbau der Regel besteht aus einem Scheduled Trigger, einem Assets-Branch und vier Aktionen pro verarbeitetem Projektobjekt:

Scheduled Trigger

Assets:
ObjectType = Projekt

    GET
    /4/projects/{Tempo Project ID}/financials/summary

    Assets Object Update

    GET
    /4/projects/{Tempo Project ID}

    Assets Object Update

Die Regel ist derzeit mit einer stündlichen Ausführung konfiguriert und verarbeitet innerhalb des Assets-Branches alle Objekte des Typs „Projekt“.

Bei ungefähr 65 Projektobjekten passen die von Atlassian ausgewiesenen durchschnittlich 260 Steps pro Run ziemlich genau zu dieser Struktur.

Die Automation ist dabei weder außergewöhnlich groß noch besonders exotisch.

Solche Regeln finden sich insbesondere in Jira-Service-Management- und Assets-Umgebungen regelmäßig.

Die Ausführungshäufigkeit wird erheblich wichtiger

Neben dem Aufbau einer Automation ist die Frequenz entscheidend.

Eine Automation mit ungefähr 260 Steps pro Ausführung erzeugt bei stündlicher Ausführung theoretisch:

260 Steps
× 24 Ausführungen
× 30 Tage

= 187.200 Steps pro Monat

Würde dieselbe Verarbeitung nur einmal täglich durchgeführt, wären es:

260 × 30
= 7.800 Steps

Bei einer wöchentlichen Aktualisierung wären es nur noch ungefähr:

260 × 4
= 1.040 Steps

Damit sollte bei jeder Scheduled Automation zukünftig eine einfache Frage gestellt werden:

Wie aktuell müssen diese Daten tatsächlich sein?

Finanzinformationen, Stammdaten oder Reportingwerte müssen beispielsweise häufig nicht jede Stunde aktualisiert werden. Eine Reduzierung der Ausführungsfrequenz kann in solchen Fällen die Nutzung erheblich reduzieren, ohne den fachlichen Prozess einzuschränken.

Ein kleines Jira-System ist nicht automatisch ein System mit geringer Automation-Nutzung

Die enthaltene Allowance hängt unter anderem von den vorhandenen Atlassian-Produkten, Plänen und Benutzerzahlen ab. Die Automation Steps werden organisationsweit gepoolt.

Das führt zu einem wichtigen Effekt:

Ein Unternehmen mit wenigen Benutzern erhält entsprechend ein kleineres Kontingent. Gleichzeitig kann eine technische Automation unabhängig von der Benutzerzahl sehr viele Objekte oder Vorgänge verarbeiten.

Ein Unternehmen mit beispielsweise 20 oder 30 Jira-Benutzern kann trotzdem:

• mehrere hundert Assets-Objekte verwalten,

• Daten aus ERP-, CRM- oder HR-Systemen synchronisieren,

• regelmäßig REST-Schnittstellen abfragen,

• SLA-Eskalationen automatisieren,

• Projektinformationen aggregieren oder

• Vorgänge regelmäßig über JQL verarbeiten.

Die Benutzerzahl ist deshalb kein geeigneter Indikator dafür, ob das neue Modell relevant wird.

Gerade kleinere Umgebungen sollten ihre Usage prüfen.

Was passiert, wenn die Allowance ausgeschöpft ist?

Dieser Punkt ist für den operativen Betrieb wichtiger als die reine Preisfrage.

Atlassian unterscheidet zwischen enthaltener Usage und zusätzlicher Usage.

Ist zusätzliche Usage aktiviert, können metered features nach Verbrauch des enthaltenen Kontingents weiter genutzt werden. Die zusätzliche Nutzung wird anschließend berechnet. Administratoren können hierfür Limits konfigurieren.

Ist Extra Usage nicht aktiviert und die Organisation hat 100 Prozent ihrer Allowance verbraucht, weist Atlassian darauf hin, dass metered features bis zum nächsten Billing Cycle eingeschränkt werden können.

Atlassian benachrichtigt Organization und Billing Admins bei 80 und 100 Prozent Nutzung.

Für Administratoren ergibt sich daraus eine neue betriebliche Aufgabe.

Es sollte nicht nur geprüft werden wie viele Steps verbrauchen wir? Sondern auch welche Prozesse funktionieren nicht mehr ordnungsgemäß, wenn Jira Automation nicht mehr ausgeführt wird?

Das können sehr unterschiedliche Prozesse sein.

Beispielsweise:

• automatische Zuweisung von Incidents

• Eskalationen

• Genehmigungsprozesse

• Erstellung von Folgeaufgaben

• Synchronisation zwischen Jira-Projekten

• Synchronisation zwischen Jira und Assets

• Aktualisierung von Stammdaten

• Onboarding- und Offboarding-Prozesse

• Kommunikation mit Kunden

• automatische Verknüpfung von Service- und Entwicklungsvorgängen

• REST-basierte Integrationen

Bei solchen Regeln sollte bekannt sein, welche fachlichen Auswirkungen ein Ausfall hat.

Wie Kunden ihre Umgebung konkret prüfen können

Der erste Schritt sollte keine technische Migration sein, sondern eine Bestandsaufnahme.

In der Administration kann die organisationsweite Nutzung des Automation-Meters geprüft werden. Zusätzlich stellt Jira innerhalb der Automation-Nutzung eine Vorschau auf das kommende Usage-Modell zur Verfügung.

Interessant sind dort insbesondere drei Werte:

• Flow runs (Wie häufig wurde die Automation ausgeführt?)

• Automation steps (Wie viele Steps haben diese Ausführungen tatsächlich verursacht?)

• Steps per Run (Dieser Wert lässt sich aus den beiden vorherigen Werten ableiten und ist für die technische Analyse besonders hilfreich.)

Eine Regel mit:

10.000 Runs
20.000 Steps

ist strukturell zunächst weniger auffällig als eine Regel mit:

100 Runs
30.000 Steps

Die zweite Regel erzeugt durchschnittlich 300 Steps pro Ausführung. Hier sind Branches, Loops oder umfangreiche Verarbeitung sehr wahrscheinlich.

Wir würden bei einer Analyse zunächst nach der absoluten Step-Anzahl sortieren und anschließend die Regeln mit einem hohen Verhältnis von Steps zu Runs untersuchen.

Besonders relevante Muster

Bei einem Review sollten insbesondere folgende Konstruktionen geprüft werden.

Scheduled Rules

Zeitgesteuerte Regeln laufen unabhängig davon, ob tatsächlich etwas zu verarbeiten ist.

Beispiel:

jede Stunde
→ suche alle offenen Vorgänge
→ prüfe jeden Vorgang
→ führe Aktionen aus

Hier sollte geprüft werden, ob ein Event Trigger verwendet werden kann oder zumindest die Ergebnismenge bereits in der Abfrage stärker eingeschränkt werden kann.

Branches über Vorgänge oder Assets

Eine Aktion innerhalb eines Branches wird möglicherweise für sehr viele Elemente ausgeführt.

Aus:

Branch
    → Condition
    → Action
    → Action

können bei 500 Elementen schnell mehr als 1.500 Steps entstehen.

REST-Integrationen

Mehrere Web Requests innerhalb eines Branches skalieren direkt mit der Anzahl der verarbeiteten Elemente.

Lookup und anschließende Verarbeitung

Regeln, die zunächst große Ergebnismengen ermitteln und anschließend einzeln verarbeiten, sollten hinsichtlich ihrer tatsächlichen Notwendigkeit geprüft werden.

Globale Trigger mit nachgelagerten Conditions

Wenn eine Regel auf sehr viele Ereignisse reagiert und erst anschließend über mehrere Conditions feststellt, dass nichts zu tun ist, entsteht unnötige Verarbeitung.

Filter sollten deshalb möglichst früh angewendet werden. Atlassian unterstützt Conditions bereits auf Trigger-Ebene, sodass der nachfolgende Flow entsprechend eingeschränkt werden kann.

Alternative 1: Jira Automation optimieren

Die erste Option sollte grundsätzlich die Optimierung der vorhandenen Regel sein.

Ein Wechsel der Technologie erzeugt Entwicklungs- und Betriebsaufwand und ist nicht automatisch sinnvoll.

Typische Maßnahmen sind:

• Ausführungsfrequenz reduzieren

• JQL- und AQL-Abfragen präzisieren

• nur geänderte Daten verarbeiten

• Bedingungen möglichst früh anwenden

• unnötige Branches entfernen

• mehrere Änderungen zusammenfassen

• redundante REST-Abfragen vermeiden

• Daten aus einem REST-Aufruf mehrfach verwenden

• ereignisbasierte Trigger statt Polling einsetzen

Bei unserer Beispiel-Regel wäre beispielsweise zu prüfen, ob beide Tempo-Endpunkte bei jeder Ausführung benötigt werden und ob sämtliche Projektobjekte stündlich aktualisiert werden müssen.

Allein eine Umstellung von stündlich auf täglich würde den theoretischen Verbrauch von rund 187.000 auf ungefähr 7.800 Steps pro Monat reduzieren.

Alternative 2: Logik direkt im Jira Workflow abbilden

Viele Automationsregeln werden verwendet, obwohl die entsprechende Logik unmittelbar Bestandteil eines Workflows ist.

Typische Beispiele sind:

Transition nach Done
→ Resolution setzen

oder:

Transition nach Freigabe
→ prüfen, ob Feld X gefüllt ist

oder:

Transition
→ Assignee setzen

Hier sollte geprüft werden, ob Conditions, Validators oder Post Functions im Workflow geeigneter sind.

Ein Validator verhindert beispielsweise eine Transition, wenn notwendige Daten fehlen.

Das ist fachlich häufig sauberer als:

Transition
→ Automation startet
→ Daten prüfen
→ Fehler feststellen
→ Vorgang zurücksetzen oder Kommentar erzeugen

Ein ungültiger Zustand sollte nach Möglichkeit gar nicht erst entstehen.

Als Architekturregel kann deshalb gelten: Logik, die unmittelbar zu einer Transition gehört, zunächst im Workflow prüfen.

Alternative 3: ScriptRunner und vergleichbare Apps

Bei komplexerer Jira-interner Logik kann ScriptRunner eine Alternative zu großen Automation Rules sein.

Das gilt insbesondere dann, wenn ScriptRunner beim Kunden bereits lizenziert und organisatorisch etabliert ist.

Mögliche Mechanismen sind beispielsweise:

• Script Listener

• Scheduled Jobs

• Workflow Conditions

• Workflow Validators

• Workflow Post Functions

Statt eine komplexe Verarbeitung über zahlreiche Automation-Komponenten abzubilden, kann die Logik programmatisch umgesetzt werden.

Beispielsweise:

Issue Updated
→ Listener
→ fachliche Bedingungen prüfen
→ weitere Daten lesen
→ Berechnung durchführen
→ Jira aktualisieren

Die interne Programmlogik besteht dann nicht aus einer großen Anzahl einzelner Automation Steps.

Das bedeutet allerdings nicht, dass ScriptRunner grundsätzlich die bessere Lösung ist.

Ein einfaches:

Issue erstellt
→ Team setzen

ist als Jira Automation für Administratoren wesentlich leichter nachvollziehbar als ein eigenes Script.

Mit ScriptRunner entstehen zudem andere Anforderungen an Betrieb und Governance:

• Source-Code-Verwaltung

• Dokumentation

• Fehlerbehandlung

• Logging

• Testing

• Kenntnisse in Groovy bzw. den jeweiligen APIs

• Abhängigkeit von einer zusätzlichen App

ScriptRunner sollte deshalb vor allem dort eingesetzt werden, wo die Komplexität eine programmatische Umsetzung tatsächlich rechtfertigt.

Alternative 4: Atlassian Forge

Eine weitere Möglichkeit ist Forge.

Forge eignet sich insbesondere für Atlassian-spezifische Erweiterungen, bei denen Businesslogik programmatisch umgesetzt werden soll.

Eine Verarbeitung könnte beispielsweise über ein Jira-Event gestartet werden:

Jira Event
→ Forge Function
→ Business Logic
→ REST API
→ Jira / Assets aktualisieren

Auch zeitgesteuerte Verarbeitungen sind möglich.

Damit lässt sich umfangreichere Logik außerhalb des Automation Flow Builders implementieren.

Forge sollte allerdings nicht als kostenloser Ersatz für Jira Automation betrachtet werden. Forge besitzt eigene Quotas und ein eigenes nutzungsabhängiges Kostenmodell. Compute, Storage und weitere Ressourcen können dort ebenfalls relevant werden.

Die Entscheidung sollte deshalb anhand der technischen Anforderungen erfolgen.

Alternative 5: Eine vorhandene Integrationsplattform nutzen

Viele Unternehmen verfügen bereits über Integrations- oder Automatisierungsplattformen.

Dazu können beispielsweise gehören:

• n8n

• Microsoft Power Automate

• Make

• Azure Logic Apps

• andere iPaaS-Lösungen

Bei einer Integration zwischen Jira und einem externen System kann es sinnvoll sein, Jira Automation nur noch als Auslöser zu verwenden.

Beispielsweise:

Jira Event
→ Webhook
→ Integrationsplattform
→ Verarbeitung
→ ERP
→ CRM
→ Jira REST API

Die komplexe Verarbeitung findet dann nicht innerhalb von Jira Automation statt.

Insbesondere Transformationen, Schleifen, Retry-Mechanismen und Integrationen mehrerer Systeme sind häufig ohnehin Aufgaben einer Integrationsplattform und nicht eines Jira-Workflow-Tools.

Alternative 6: Eigener Integrationsservice

Bei größeren oder geschäftskritischen Integrationen kann ein eigener Service die technisch sauberste Lösung sein.

Ein solcher Service kann beispielsweise auf Jira-Webhooks reagieren und anschließend die notwendige Verarbeitung durchführen.

Eine typische Architektur könnte aus folgenden Komponenten bestehen:

Jira
  ↓
Webhook
  ↓
Integration Service
  ↓
Queue
  ↓
Business Logic
  ↓
Jira / Assets / ERP / CRM

Hier können Funktionen umgesetzt werden, die in Jira Automation nur eingeschränkt möglich sind:

• kontrollierte Parallelisierung

• Queuing

• Retry mit Backoff

• Caching

• Delta-Synchronisation

• dedizierte Logs

• Metriken

• Monitoring

• Alerting

• automatisierte Tests

Der Entwicklungs- und Betriebsaufwand ist entsprechend höher. Für eine einfache Jira-Automation wäre diese Architektur überdimensioniert. Bei geschäftskritischen Integrationen mit hohen Datenmengen kann sie dagegen erheblich besser kontrollierbar sein.

Event-driven statt Polling

Unabhängig von der verwendeten Technologie ist eine Frage besonders relevant:

Muss ein System regelmäßig prüfen, ob sich etwas verändert hat, oder kann die Änderung selbst den Prozess auslösen?

Polling:

alle 60 Minuten
→ 1.000 Datensätze prüfen
→ 5 haben sich verändert

verarbeitet regelmäßig 1.000 Datensätze, obwohl nur fünf relevant sind.

Event-driven:

Datensatz 1 geändert → verarbeiten
Datensatz 2 geändert → verarbeiten
Datensatz 3 geändert → verarbeiten
Datensatz 4 geändert → verarbeiten
Datensatz 5 geändert → verarbeiten

reduziert die Verarbeitung auf die tatsächlich relevanten Änderungen.

Nicht jede API und nicht jedes System stellt geeignete Events oder Webhooks bereit. Wo dies möglich ist, sollte diese Variante bei häufig ausgeführten Synchronisationsprozessen aber geprüft werden.

Nicht nur die Kosten berechnen

Ein technischer Umbau sollte nicht durchgeführt werden, nur weil eine Automation viele Steps erzeugt.

Atlassian bietet zusätzliche Automation Usage an. Usage Packs beginnen derzeit bei 40.000 Steps; Atlassian nennt hierfür 0,50 US-Dollar pro 1.000 Steps.

40.000 zusätzliche Steps entsprechen damit 20 US-Dollar.

Selbst wenn eine bestehende Automation monatlich zusätzliche Kosten verursacht, kann deren Weiterbetrieb wirtschaftlich wesentlich sinnvoller sein als eine Neuentwicklung.

Angenommen eine Umstellung auf Forge oder einen eigenen Service benötigt drei Beratungstage. Bei üblichen Beratungs- und Entwicklungskosten steht diesem einmaligen Aufwand möglicherweise lediglich eine Einsparung von einigen zehn Euro pro Monat gegenüber.

Eine reine Kostenbetrachtung würde hier zu einer falschen Architekturentscheidung führen.

Neben den Kosten sollten mindestens folgende Punkte betrachtet werden:

• Wartbarkeit

• technische Komplexität

• Kritikalität des Prozesses

• Ausfallrisiko

• Datenmenge

• Wachstum

• vorhandene Technologien

• vorhandenes Know-how

• Monitoring

• Fehlerbehandlung und zukünftige Weiterentwicklung.

Kritische Automationen identifizieren

Nicht jede Automation benötigt dieselbe Aufmerksamkeit.

Wir würden Regeln zusätzlich nach ihrer betrieblichen Bedeutung klassifizieren.

Unkritisch

Beispielsweise automatische Labels, Komfortfunktionen oder interne Benachrichtigungen.

Ein temporärer Ausfall ist ärgerlich, beeinflusst aber keinen wesentlichen Geschäftsprozess.

Relevant

Beispielsweise automatische Zuweisungen, Synchronisationen oder Reportingdaten.

Ein Ausfall sollte erkannt und zeitnah behoben werden.

Geschäftskritisch

Beispielsweise Incident Routing, sicherheitsrelevante Prozesse, On-/Offboarding, externe Integrationen oder Automationen, auf deren Ausführung nachgelagerte Systeme angewiesen sind.

Bei diesen Regeln sollte bekannt sein, was bei Erreichen des Usage Limits passiert und wie der Prozess alternativ weitergeführt werden kann.

Ein möglicher technischer Review

Für bestehende Jira-Cloud-Umgebungen würden wir die Analyse in mehreren Schritten durchführen.

Zunächst werden die organisationsweite Allowance, die aktuelle Usage und die Konfiguration für Extra Usage geprüft. Danach werden die Automation Rules nach ihrer Step-Nutzung sortiert. Für die größten Verbraucher werden mindestens folgende Werte erfasst:

Kennzahl	Bedeutung
Runs pro Monat	Wie häufig wird die Regel ausgeführt?
Steps pro Monat	Absoluter Verbrauch
Steps pro Run	Komplexität einer einzelnen Ausführung
Trigger	Event-driven oder Scheduled?
Branches	Werden Listen verarbeitet?
Anzahl Elemente	Wie viele Issues/Objekte werden typischerweise verarbeitet?
REST Calls	Werden externe Systeme angesprochen?
Frequenz	Wie häufig muss die Verarbeitung fachlich wirklich erfolgen?
Kritikalität	Was passiert bei einem Ausfall?
Alternative	Workflow, Automation, Script, Forge oder Integration?

Danach lässt sich wesentlich gezielter entscheiden.

Eine Regel mit 50.000 Steps pro Monat muss nicht automatisch geändert werden.

Eine Regel mit 5.000 Steps kann dagegen kritisch sein, wenn sie einen geschäftsrelevanten Prozess steuert und nach Erreichen eines Limits nicht mehr ausgeführt werden könnte.

Unsere Empfehlung für neue Automationen

Für neue Anforderungen würden wir zukünftig stärker zwischen verschiedenen Arten von Logik unterscheiden.

Workflow-Logik

Wenn eine Regel unmittelbar Bestandteil eines Statusübergangs ist, zunächst Conditions, Validators und Post Functions prüfen.

Einfache Automatisierung

Für überschaubare ereignisbasierte Aktionen weiterhin Jira Automation verwenden.

Komplexe Jira-interne Logik

Bei vielen Bedingungen, umfangreicher Datenverarbeitung oder bereits vorhandenem ScriptRunner prüfen, ob eine programmatische Umsetzung sinnvoller ist.

Integration

Sobald Jira mit mehreren externen Systemen synchronisiert wird, prüfen, ob eine Integrationsplattform oder ein eigener Service geeigneter ist.

Batch Processing

Große Mengen an Issues oder Assets-Objekten regelmäßig zu durchlaufen sollte bewusst als Batch-Verarbeitung betrachtet werden. Jira Automation kann das technisch ermöglichen, ist aber nicht zwangsläufig die sinnvollste Ausführungsplattform.

Was Administratoren jetzt konkret tun sollten

Für bestehende Jira-Cloud-Umgebungen besteht aus unserer Sicht kein Grund für hektische Migrationen. Es gibt aber einen konkreten Prüfbedarf.

Zunächst sollte in der Atlassian Administration kontrolliert werden, wie hoch die organisationsweite Automation-Step-Allowance ist und ob Extra Usage aktiviert wurde.

Danach sollte die Vorschau des neuen Usage-Modells in Jira Automation geprüft werden. Entscheidend sind nicht nur die Gesamtwerte, sondern insbesondere die Regeln mit dem höchsten Verbrauch.

Für diese Regeln sollte anschließend nachvollzogen werden, wodurch die Steps entstehen.

Bei Scheduled Rules sollte die notwendige Frequenz hinterfragt werden.

Bei Branches sollte geprüft werden, wie viele Elemente durchschnittlich verarbeitet werden.

Bei REST-basierten Regeln sollte geprüft werden, ob mehrere Aufrufe zusammengefasst oder vermieden werden können.

Bei Workflow-bezogener Logik sollte geprüft werden, ob Conditions, Validators oder Post Functions geeigneter sind.

Bei komplexer Jira-interner Logik können vorhandene Apps wie ScriptRunner eine Alternative sein.

Bei großen Datenmengen und systemübergreifenden Prozessen sollte geprüft werden, ob die Verarbeitung in einer Integrationsplattform, Forge oder einem eigenen Service besser aufgehoben ist.

Und bei geschäftskritischen Regeln sollte dokumentiert sein, was passiert, wenn die Automation nicht ausgeführt wird.

Fazit

Das neue Automation-Step-Modell macht bestimmte technische Eigenschaften von Jira Automation erstmals unmittelbar nutzungsrelevant.

Eine einfache Automation mit wenigen Aktionen bleibt auch zukünftig eine sinnvolle und wartbare Lösung.

Anders sieht es bei Regeln aus, die große Mengen an Issues oder Assets-Objekten durchlaufen, regelmäßig pollen, umfangreiche Branches verwenden oder externe Systeme über mehrere REST-Aufrufe integrieren.

Unser Beispiel zeigt die Größenordnung: 137 Ausführungen einer einzelnen Automation erzeugen 35.620 Automation Steps.

Zwei Regeln verursachen in diser Umgebung rund 95 Prozent der gesamten Step-Nutzung.

Das ist vor allem deshalb relevant, weil diese Umgebung weder besonders groß ist noch ungewöhnlich viele Automation Runs erzeugt.

Unternehmen sollten deshalb nicht anhand ihrer Benutzerzahl oder der Anzahl vorhandener Regeln beurteilen, ob die Änderung für sie relevant ist.

Entscheidend ist, was diese Regeln tatsächlich tun.

Für bestehende Umgebungen ist die neue Usage-Auswertung deshalb ein guter Ausgangspunkt für einen technischen Review. Dabei sollte nicht das Ziel sein, Jira Automation grundsätzlich zu vermeiden oder jeden zusätzlichen Step einzusparen.

Das Ziel sollte sein, die richtige technische Ebene für die jeweilige Aufgabe zu verwenden und gleichzeitig zu wissen, welche betrieblichen Auswirkungen ein ausgeschöpftes Automation-Kontingent haben kann.