Jira Service Management ist eine leistungsfähige Plattform. Die eingebauten Automatisierungsregeln decken die einfachen Fälle gut ab: Tickets automatisch zuweisen, Benachrichtigungen verschicken, Statusübergänge auslösen. Viele Teams können so 80 Prozent ihrer täglichen Arbeit erledigen.
Aber ITSM in der Praxis bleibt selten so überschaubar. Der reale Service-Betrieb erfordert teamübergreifende Eskalationen, SLA-Ausnahmen, die von Kundenverträgen abhängen, abteilungsübergreifende Genehmigungsworkflows und Kundenportale, die interne Daten in Echtzeit widerspiegeln müssen. Wer diese Fälle mit nativen JSM-Regeln abbilden will, landet typischerweise bei ausufernden, fragilen Regelketten – oder bei Workarounds, die so lange funktionieren, bis sie zusammenbrechen, was gemäß Murphy’s Law bekanntlich gerne in einem entscheidenden Moment passiert.
Genau hier eröffnet Atlassian Forge einen anderen Weg. Statt Automatisierungsregeln über ihre eigentliche Intention hinaus zu dehnen, ermöglicht Forge die Implementierung genau der Logik, die Ihre eigenen ITSM-Prozesse tatsächlich brauchen – sicher, innerhalb der Atlassian-Plattform und ohne externe Infrastruktur.
Wo die native JSM-Automatisierung an ihre Grenzen stößt
Bevor es darum geht, was Forge hier leisten kann, lohnt sich ein genauer Blick auf die funktionellen Lücken.
Die native Automatisierung von JSM ist regelbasiert und linear. Sie funktioniert gut, wenn sich Trigger, Bedingung und Aktion als klare Abfolge ausdrücken lassen. Service-Management-Workflows verlangen aber häufig mehr:
- Verzweigungslogik über mehrere Kriterien gleichzeitig – beispielsweise das Routing eines Tickets anhand der Kombination aus Kundenstufe, Problemkategorie und aktueller Auslastung des zuständigen Teams.
- Integration externer Systeme zur Entscheidungszeit – Abfrage einer Configuration Management Database (CMDB), eines HR-Systems für Bereitschaftspläne oder eines SLA-Vertrags, bevor priorisiert wird.
- Dynamische UI-Komponenten im Kundenportal – Anfragestatus, verknüpfte Assets oder kontextabhängige Informationen, die sich je nach Anfragetyp anpassen.
- Proaktive Überwachungslogik – um SLA-Risiken zu erkennen, bevor eine Verletzung eintritt, statt anschließend zu reagieren.
Diese Szenarien sind im nativen JSM nicht grundsätzlich unmöglich, aber sie erfordern Kompromisse oder zusätzliche Werkzeuge. Forge beseitigt diese Trade-offs.
Drei konkrete Use Cases
1. Intelligentes Ticket-Routing
Die Standard-Zuweisungsregeln in JSM arbeiten mit einfachen Bedingungen. Ein reales Routing-Problem sieht oft so aus: Eine Hardware-Anfrage eines Nutzers in Frankfurt soll an das EMEA-Hardware-Team gehen – aber nur, wenn dieses Team weniger als 15 offene Tickets hat. Andernfalls landet die Anfrage in der globalen Queue. Ist die Anfrage als dringend markiert, soll die Teamleitung sofort per Slack informiert werden.
Mit einer Forge-App lebt diese Logik in einer einzigen, versionierten Funktion, die beim Erstellen eines Issues ausgelöst wird. Sie kann die Jira-API abfragen, um Queue-Auslastungen zu prüfen, einen externen Slack-Webhook aufrufen (sofern die Slack-Domain in den erlaubten Egress-Domains der App eingetragen ist) und Zuweisung sowie Priorität des Tickets in einem kohärenten Ablauf aktualisieren. Die Logik ist nachvollziehbar, testbar und einfach anpassbar, wenn sich Teamstrukturen ändern.
Das ist eine deutliche Verbesserung gegenüber dem Versuch, dasselbe Verhalten über verschachtelte Automatisierungsregeln abzubilden, bei denen die Ausführungsreihenfolge schwer nachvollziehbar ist und die Fehlersuche durch jede einzelne Regel führt.
2. Proaktives SLA-Monitoring mit gezielter Eskalation
Die meisten Teams überwachen SLAs reaktiv: Ein Alert wird ausgelöst, wenn eine Verletzung eingetreten ist. Zu diesem Zeitpunkt ist der Schaden allerdings bereits entstanden. Ein Forge-basierter Ansatz kann dieses Modell in einen proaktiven Ansatz verwandeln.
Eine geplante Forge-Funktion kann beispielsweise alle 15 oder 30 Minuten laufen, alle offenen Tickets mit aktiven SLAs abfragen und die verbleibende Zeit gegen den aktuellen Status berechnen. Tickets, die ein konfigurierbares Warnfenster erreichen – etwa weniger als 20 Prozent der SLA-Zeit verbleibend –, lösen gezielte Benachrichtigungen an den zuständigen Agenten und die Teamleitung aus. Bleibt eine Reaktion aus und schrumpft das Zeitfenster weiter, eskaliert das System automatisch weiter.
Diese Art von Logik erfordert persistente Zustände (welches Ticket wurde bereits auf welcher Stufe eskaliert?) und eine zeitgesteuerte Ausführung – beides deckt Forge nativ über seine Storage-APIs und Scheduled Triggers ab. Das Ergebnis ist ein Eskalationsmodell, das proaktiv, nachvollziehbar und ohne ein separates Monitoring-Tool auskommt.
3. Dynamische Erweiterungen des Kundenportals
Das JSM-Kundenportal ist funktional, aber starr. Jeder Kunde sieht dieselbe Formularstruktur, dieselben Statusbezeichnungen und denselben Detailgrad – unabhängig von seinem Vertrag, seiner Geschichte mit dem Service-Team oder der Art seiner Anfrage.
Mit dem UI Kit und den Custom-UI-Möglichkeiten von Forge wird das Portal erweiterbar. Eine Forge-App kann Panels in der Request-Detailansicht ergänzen sowie Header und Footer des Portals mit maßgeschneiderten Inhalten befüllen: Asset-Informationen aus einer integrierten CMDB einblenden, kundenbezogenen Support-Kontext anzeigen oder vertraglich zugesicherte Reaktionszeiten direkt neben der Anfrage sichtbar machen.
Das ist besonders relevant für Enterprise-Service-Desks, die Kunden mit unterschiedlichen Vertragsmodellen bedienen. Ein Kunde mit Premium-Support sieht seine dedizierten Ansprechpartner und die vertraglich zugesicherten Reaktionszeiten. Ein Standard-Kunde sieht die allgemeine Queue. Das Portal spiegelt die tatsächliche Service-Beziehung wider, statt eine Einheitslösung zu präsentieren.
Wie Forge technisch mit JSM zusammenspielt
Einige Forge-Funktionen sind im JSM-Kontext besonders relevant:
Event Trigger auf Issue-Lifecycle-Events (avi:jira:created:issue, avi:jira:updated:issue etc.) ermöglichen es Forge-Funktionen, sofort zu reagieren, wenn Tickets erstellt, übergeleitet oder geändert werden – ohne Polling.
Scheduled Trigger übernehmen zeitbasierte Logik wie das SLA-Monitoring, ohne externe Cron-Infrastruktur zu benötigen.
Forge Storage und Forge SQL liefern Persistenz für Zustand, der über einzelne Invocations hinaus erhalten bleiben muss: Eskalationsstufen tracken, Lookup-Daten cachen oder kundenspezifische Konfigurationen verwalten.
UI Kit und Custom UI ermöglichen Frontend-Erweiterungen im Kundenportal und in der Agentenansicht von JSM: dynamische, datengetriebene Komponenten, ohne das Sicherheitsmodell der Plattform zu verlassen.
Forge Remote verbindet Apps mit externen Systemen – CMDBs, HR-Verzeichnisse, Monitoring-Tools – innerhalb der sicheren Egress-Kontrollen von Forge und hält Datenflüsse nachvollziehbar und compliant.
Warum Forge statt ein externes Automatisierungstool?
Teams, die diese Frage evaluieren, denken häufig auch über Tools wie n8n, Zapier oder eigene Webhook-Receiver nach. Diese können funktionieren, aber machen Kompromisse nötig, die im ITSM-Kontext relevant sind.
Externe Tools liegen außerhalb der Atlassian-Vertrauensgrenze. Daten, die durch sie fließen, verlassen die Plattform, was DSGVO-Compliance, Data-Residency-Garantien und Sicherheitsaudits verkompliziert. Außerdem erfordern sie ein eigenes Authentisierungs-Management, ein eigenes Monitoring und eine eigene Fehlerbehandlung. Wenn nachts um zwei Uhr etwas schiefläuft, führt die Debugging-Spur über Systemgrenzen hinweg.
Forge hält alles innerhalb der Atlassian-Plattform. Ausführungs-Logs sind in der Developer Console zugänglich. In Forge Storage gespeicherte Daten unterliegen denselben Data-Residency-Kontrollen wie der Rest der Atlassian-Instanz. Sicherheits- und Compliance-Audits erfassen das gesamte System, kein Flickwerk aus Integrationen.
Hinzu kommt die Frage des Ausführungskontexts. Forge-Funktionen laufen mit dem Sicherheitskontext des auslösenden Nutzers oder als definierter App-Principal – was in JSM direkte Auswirkung darauf hat, welche Daten sichtbar sind und welche Aktionen erlaubt werden. Ein externes Tool löst das über eigene API-Token und Service-Accounts. Das funktioniert, schwächt aber den Audit-Trail. Wenn ein Compliance-Team fragt, wer einen Workflow ausgelöst hat und mit welchen Berechtigungen, liefert Forge eine klare Antwort.
Das ist dasselbe Argument, das bereits im Beitrag zu Forge vs. Connect formuliert wurde: Die Plattformgrenze hat Bedeutung – und Forge hält die eigene Lösung innerhalb dieser Grenze.
Wo anfangen?
Der Einstieg ist einfacher, als er auf den ersten Blick erscheint. Eine einzige Forge-Funktion, die auf avi:jira:created:issue reagiert, kann eine Routing-Logik implementieren, die die Ticketverteilung sofort verbessert – mit sichtbaren Ergebnissen vom ersten Tag an.
Von hier aus ist das SLA-Monitoring als Scheduled Trigger ein natürlicher zweiter Schritt. Kundenportal-Erweiterungen kommen typischerweise später, sobald die Backend-Logik stabil ist und das Team mit den UI-Möglichkeiten von Forge vertraut ist.
Der Schlüssel liegt darin, mit demjenigen Workflow zu beginnen, der heute am meisten Reibung erzeugt. In den meisten Service-Management-Umgebungen ist das entweder die Genauigkeit beim Routing oder die SLA-Eskalation. Wählen Sie einen Prozess, der Schmerzen verursacht, bauen Sie eine fokussierte Forge-App darum herum – und der Weg zur breiteren Automatisierung wird klarer.
Forge ersetzt die native Automatisierung von JSM nicht, sondern erweitert sie in den Bereich, wo native Regeln an ihre Grenzen stoßen. Für ITSM-Teams, die mit komplexem Routing, proaktivem SLA-Management oder differenzierten Kundenerlebnissen zu tun haben, ist genau diese Erweiterung der Unterschied zwischen einem Service Desk, der mithält, und einem, der vorausdenkt.
Plant Ihr Team den Einsatz von Forge für JSM oder möchten Sie Ihre Automatisierungsstrategie modernisieren? Unsere erfahrenen Atlassian-Entwicklungsteams unterstützen Sie bei Architektur, Entwicklung und Zertifizierung. Melden Sie sich per E-Mail oder vereinbaren Sie direkt einen Remote-Termin mit uns!