Building Blocks
Workflows
Der Lebenszyklus eines Tickets, Configuration Items oder einer Aufgabe — eine Abfolge von Status und die Regeln, wer von welchem Status zu welchem wechseln darf.
Aktualisiert am 23. Jan. 2026
Konfiguration · Building Blocks · 3.6
Ein Workflow ist eine Menge von Status + die Übergänge dazwischen + wer welchen Übergang ausführen darf. Jedes Ticket, jedes Configuration Item und jede Aufgabe ist an einen Typ gekoppelt — und der Workflow hängt an diesem Typ. Gut entworfene Workflows = ein klarer Prozessfluss; schlecht entworfen = „Wie ist eigentlich der Status dieses Tickets?“.
Warum das für das Business zählt
„Niemand weiß, wann etwas fertig ist“
Statusnamen, die das Business versteht — nicht „Status 3“ oder „Pending review“.
„Jeder schließt jedes Ticket“
Übergänge sind rollenspezifisch — nur Manager schließen, Bearbeiter lösen.
„Freigabe steckt in einer Excel“
Genehmigungsstatus im Workflow selbst — inklusive, wer freigeben darf und was als Nächstes folgt.
„Anderer Ablauf je Typ“
Ein Incident hat andere Schritte als ein Zugriffsantrag — jeder erhält einen eigenen Workflow.
Der Mechanismus
Typ
Tickettyp, CI-Typ oder Aufgabentyp. Bestimmt, welcher Workflow auf einen Datensatz angewendet wird.
Status
Die Phasen, die ein Datensatz durchläuft. Ein neuer Typ wird mit vier Standard-Status ausgeliefert (siehe unten).
Übergänge
Erlaubte Wechsel zwischen Status, plus welche Berechtigungsgruppen sie ausführen dürfen.
Die vier Standardstatus
Für jeden neuen Ticket-, CI- oder Aufgabentyp legt Gfacility automatisch vier Status an:
| Statustyp | Rolle |
|---|---|
| Standardstatus | Startpunkt. Jeder neue Datensatz landet hier automatisch. |
| Genehmigungsstatus | Wartet auf Freigabe. Optional, aber sinnvoll für Change-/Finance-Flows. |
| Stornierungsstatus | Vom Anforderer zurückgezogen — nicht dasselbe wie abgelehnt. |
| Ablehnungsstatus | Vom Bearbeiter/Genehmiger abgelehnt. Endstatus. |
Zusätzlich zu diesen vier können Sie eigene Status frei ergänzen (In Bearbeitung, Eingeplant, Blockiert, Warten auf Kunde, Gelöst, Verifiziert, …). Jeder Status erhält eine eigene Textfarbe und Hintergrundfarbe für die visuelle Erkennbarkeit.
Welche Entscheidungen treffen Sie?
Wie viele Status je Typ?
5–7 werden empfohlen. Mehr = Verwirrung; weniger = zu grob fürs Reporting.
Welche Übergänge sind erlaubt?
Blockiert → Gelöst steht allen offen, aber Verifiziert → Wiedereröffnet nur dem Melder.
Welche Gruppe darf welchen Übergang ausführen?
Folgt direkt aus Ihrer RACI: Wer „A“ für einen Schritt ist, darf den Übergang in den nächsten Status auslösen.
Ein Workflow oder je Typ?
Bei wesentlich abweichenden Prozessen → separater Workflow. Sonst ein Workflow mit Varianten über Custom Fields.