So verschiebt ihr Deadlines um die Blocked-Zeit (Jira Automation)

Die Uhr für blockierte Jira-Vorgänge anhalten — zwei Automation-Regeln speichern die Pause in einer Issue-Property und verschieben die Deadline um Werktage.

Ein Vorgang hängt eine Woche in Blocked, kommt zurück nach In Progress — und gilt sofort als überfällig, weil sein Planned End Date sich nie bewegt hat. Jemand korrigiert das Datum von Hand. Nächster Sprint, gleiches Spiel.

Diese Anleitung baut die Lösung mit zwei kleinen Jira-Automation-Regeln: Verlässt ein Work Item den Status Blocked, verschiebt sich seine Deadline genau um die dort verbrachte Zeit — gerechnet in Werktagen, ohne Hilfs-Custom-Field und ohne externe Skripte. Der Trick ist ein verstecktes Jira-Feature: Issue Entity Properties.

Was wir bauen

  • Wenn ein Work Item Blocked oder Hold betritt, merken wir uns das Datum.
  • Wenn es den Status verlässt, wandert das Planned End Date um die Pausenlänge nach vorn.
  • Wochenenden zählen nicht — verschoben wird in Werktagen.
  • Ist das Deadline-Feld leer, passiert nichts.
  • Verkettete Pausen (Blocked → Hold) funktionieren einfach: Beide Regeln feuern beim Übergang.

Drei Wege, Zeit in einem Status zu messen

Ansatz Funktioniert in einer Regel? Der Haken
Changelog auslesen ❌ {{issue.changelog}} kommt in Automation leer zurück (histories=null, total=0) — die Statushistorie ist für Regeln nicht verfügbar.
Hilfs-Custom-Field ✅ Ein permanentes Feld in Screens, Exporten und Suchindex — sichtbarer Ballast für Daten, die kein Mensch sehen muss.
Issue Entity Property ✅ Unsichtbare Metadaten am Work Item: kein Feld, keine Screen-Konfiguration, nichts im Index. Einzige Lücke — Jira liefert keine UI für Properties (Lösung unten).

Entity Properties gewinnen: Sie sind genau der „Haftzettel am Vorgang", den dieser Job braucht.

Regel 1 — Pausenstart merken

Trigger: Work item transitioned → nach Blocked, Hold. Dann:

  1. Create variable time = {{now.toDays}}
  2. Set entity property am Issue: Key pause_start, Wert {{time}}

Jira-Automation-Regel setzt die Entity Property pause_start, wenn ein Work Item Blocked betritt

Regel 1 — das Pausendatum landet in einer unsichtbaren Property

{{now.toDays}} ist die Zahl der Tage seit der Epoche — ein einfacher Integer wie 20643. Warum das wichtig ist: siehe „Warum ein Integer" unten.

Regel 2 — Deadline beim Verlassen verschieben

Trigger: Work item transitioned → von Blocked, Hold. Bedingung: Planned end date ist nicht leer. Dann eine Variable formula anlegen:

{{issue.customfield_10236.plusBusinessDays(issue.customfield_10236.diff(issue.customfield_10236.plusDays(now.toDays.minus(issue.properties.pause_start))).businessDays)}}

…und Edit work item fields → Planned end date auf {{formula}} setzen.

Jira-Automation-Regel berechnet die Werktags-Verschiebung und bearbeitet das Planned end date

Regel 2 — Bedingung, Formel-Variable, Feld-Änderung

Die Formel von innen nach außen gelesen:

  1. now.toDays.minus(issue.properties.pause_start) — Kalendertage der Pause.
  2. issue.customfield_10236.plusDays(…) — ein Hilfsdatum: aktuelle Deadline plus diese Kalenderspanne.
  3. .diff(…).businessDays — Werktage zwischen Deadline und Hilfsdatum. .diff() vergleicht problemlos zwei Daten — dieser Zwei-Schritt-Umweg macht Werktags-Mathematik überhaupt erst möglich.
  4. .plusBusinessDays(…) — die eigentliche Verschiebung.

HINWEIS: customfield_10236 ist das Feld Planned end date in dieser Instanz — die eigene Feld-ID findet ihr unter Einstellungen → Vorgänge → Benutzerdefinierte Felder.

Eine Feinheit: Die Formel zählt Werktage im Verschiebefenster ab der aktuellen Deadline, nicht innerhalb der Pause selbst. Fürs Umterminieren ist genau das die richtige Frage — entscheidend ist, über wie viele Wochenenden die Deadline springt.

Eine Woche in Blocked → die Deadline wandert fünf Werktage. Keine Aufräum-Regel nötig: Die nächste Pause überschreibt pause_start einfach.

Warum ein Integer und kein Datums-String

Automation kann ein formatiertes Datum in eine Property schreiben, es aber nicht zuverlässig zurücklesen — .diff() gegen einen gespeicherten Datums-String scheitert stillschweigend. Integer-Mathematik (toDays, .minus(), .plusDays()) übersteht die Rundreise jedes Mal. Wenn eine Regel eine Property zurücklesen soll: Zahlen speichern.

Sehen, was eine Regel wirklich gespeichert hat

Entity Properties haben einen echten Nachteil: Jira hat keinen Screen, der sie anzeigt. Beim Verdrahten solcher Regeln stellen sich ständig kleine Fragen — hat Regel 1 gefeuert? Ist pause_start eine Zahl oder ein String? Was passiert, wenn ich den Wert ein paar Tage zurückdatiere, um eine lange Pause zu simulieren? Die Bordmittel: REST-API per Postman (in vielen Firmennetzen blockiert) oder Wegwerf-Regeln, die Werte loggen.

Universal Properties Editor for Jira (UPEJ) schließt genau diese Lücke: Im Tab Issue properties den Key eingeben — und jede Property des Work Items ist sichtbar und direkt editierbar, auch pause_start zwischen zwei Test-Übergängen. Eine Pause zurückzudatieren wird zum Zehn-Sekunden-Edit statt zur nächsten Debug-Regel.

UPEJ-Tab „Issue properties" zeigt die Property pause_start eines Work Items mit Edit- und Delete-Aktionen

Jede Property des Work Items — sichtbar, editierbar, löschbar

Die zwei Regeln laufen ohne jede App. Auf Properties zu bauen, ohne sie sehen zu können — da sitzt der Schmerz.

FAQ

Warum ist das Changelog in Jira-Automation-Regeln leer?

Innerhalb einer Regel liefert {{issue.changelog}} ein leeres Objekt (histories=null, total=0) — Automation stellt die Statushistorie nicht als Smart Value bereit. Zeit zwischen Übergängen muss man selbst festhalten: in einer Entity Property oder einem Feld.

Was sind Jira Issue Entity Properties?

Versteckte Key-Value-Metadaten, die Jira an Work Items (und Nutzern, Projekten, Kommentaren, Boards) speichert. Regeln, Integrationen und Apps halten damit Zustand, ohne sichtbare Felder anzulegen. Sie erscheinen weder auf Screens noch in Exporten — und Jira liefert keine UI dafür; genau das ergänzen Tools wie UPEJ.

Warum das Datum als Zahl statt als Datums-String speichern?

Ein in eine Property geschriebener Datums-String lässt sich mit .diff() nicht zurücklesen — der Vergleich scheitert stillschweigend. Ein Integer wie {{now.toDays}} (Tage seit der Epoche) übersteht die Rundreise: subtrahieren, addieren, vergleichen mit simpler Mathematik.

Berücksichtigt die Verschiebung Wochenenden?

Ja. Die Formel baut ein Hilfsdatum, nimmt .diff(…).businessDays gegen die aktuelle Deadline und wendet dann .plusBusinessDays() an — eine Pause von sieben Kalendertagen verschiebt die Deadline um fünf Werktage.

Was passiert bei Blocked → Hold → In Progress?

Beim Übergang Blocked → Hold feuern beide Regeln: Die Verlassen-Regel verschiebt die Deadline für die erste Pause, die Betreten-Regel hält sofort den Start der zweiten fest. Jede Pause wird verrechnet; pause_start wird bei jedem neuen Pausenbeginn einfach überschrieben.

Wie prüfe oder ändere ich eine Property ohne REST-API?

Im Tab Issue properties des Universal Properties Editor for Jira den Work-Item-Key eingeben und laden — alle Properties erscheinen mit Edit- und Delete-Aktionen. Praktisch, um zu prüfen, was eine Regel gespeichert hat, oder um Werte beim Testen zurückzudatieren.

Wie teste ich eine Automation-Regel, die Issue Properties nutzt?

Löst die Übergänge an einem Test-Work-Item aus und prüft die Property in UPEJ — und editiert den Wert (z. B. pause_start ein paar Tage zurückdatieren), um eine lange Pause zu simulieren, ohne zusätzliche Debug-Regeln zu schreiben.

Schaut in eure Properties

Die zwei Regeln sind so, wie sie hier stehen, kopierbar — das Einzige, was Jira euch nicht gibt, ist ein Fenster in die Properties, die sie schreiben. Universal Properties Editor for Jira ist dieses Fenster: Issue-, User-, Projekt-, Kommentar- und Board-Properties, einsehbar und editierbar von einer Admin-Seite.