Wie ich Microsoft Copilot mit Jira über eine API verbunden habe.

Das Problem: Bugs kommen dort an, wo sie am wenigsten strukturiert sind

Ein typischer Bug-Report per E-Mail kann so aussehen: „Seit dem letzten Update können mehrere Benutzer keine Bestellungen mehr abschließen. Nach dem Klick auf ‚Zahlungspflichtig bestellen‘ lädt die Seite dauerhaft. Das Problem tritt in Chrome und Edge auf. Im Anhang befindet sich ein Screenshot.“

Für einen Menschen ist schnell erkennbar, dass es sich wahrscheinlich um einen Fehler im Bestellprozess handelt. Für einen strukturierten Ticketprozess fehlen trotzdem häufig wichtige Informationen:

• Welche Anwendung oder welches Modul ist betroffen?
• Wie lässt sich der Fehler reproduzieren?
• Wie hoch ist die Auswirkung – und wie viele Benutzer sind betroffen?
• Welche Umgebung wurde verwendet?
• Wer ist für die Bearbeitung zuständig?
• Handelt es sich wirklich um einen Bug oder eher um eine Anfrage?

Die Idee: E-Mail als Eingangskanal, Jira als führendes System

Würde man solche E-Mails manuell bearbeiten, müsste jemand den Inhalt lesen, die relevanten Informationen herausfiltern, ein Jira-Ticket anlegen, die Felder pflegen und die richtige Zuständigkeit bestimmen. Bei mehreren E-Mails pro Tag entsteht schnell ein vermeidbarer manueller Aufwand.

Ich wollte den bestehenden Kommunikationsweg nicht verbieten, sondern sinnvoll integrieren. Die Anwender dürfen weiterhin eine E-Mail schreiben. Im Hintergrund wird daraus automatisch ein strukturiertes Ticket. Die Rollen der Komponenten sind dabei klar getrennt:

• Microsoft Outlook beziehungsweise das Postfach nimmt die E-Mail entgegen.
• Microsoft Copilot analysiert den Inhalt und erkennt relevante Informationen.
• Eine Integrationslogik bereitet die extrahierten Daten für Jira auf.
• Die Jira-API erstellt daraus ein neues Issue.
• Jira Automation übernimmt Kategorisierung, Priorisierung, Benachrichtigungen und Zuweisung.

Der technische Ablauf

Der automatisierte Prozess sieht vereinfacht so aus: E-Mail im Posteingang → Erkennung relevanter Nachrichten → Analyse durch Microsoft Copilot → strukturierte Ticketdaten → Jira REST API → neues Jira-Ticket → Jira Automation → Kategorisierung, Priorisierung und Zuweisung.

Zunächst wird nicht jede E-Mail an Jira weitergegeben. Die Integrationslogik prüft zum Beispiel Absender oder Absendergruppe, Zieladresse oder Betreff, bestimmte Schlüsselwörter, enthaltene Fehlermeldungen, vorhandene Anhänge oder Screenshots und ob die Nachricht bereits verarbeitet wurde. Dadurch wird verhindert, dass Newsletter, automatische Benachrichtigungen oder normale Rückfragen versehentlich als Jira-Ticket angelegt werden.

Eine mögliche Regel lautet: Wenn die E-Mail an support@unternehmen.de gesendet wurde und der Betreff Begriffe wie „Fehler“, „Bug“, „funktioniert nicht“ oder „Problem“ enthält, dann analysieren. In der Praxis sollte diese Prüfung nicht ausschließlich auf einzelne Schlüsselwörter angewiesen sein – eine Kombination aus Absenderregeln, Postfachordnern, Betreff und Inhaltsanalyse ist meist zuverlässiger.

Copilot analysiert die E-Mail

Microsoft Copilot erhält den relevanten Inhalt der Nachricht und extrahiert die Informationen, die für ein Jira-Ticket benötigt werden. Dabei geht es nicht nur darum, den E-Mail-Text zusammenzufassen. Copilot soll die Inhalte in ein definiertes Schema überführen – zum Beispiel in ein JSON-Objekt mit Feldern wie Vorgangstyp (Bug), Zusammenfassung, Beschreibung, betroffene Anwendung, Umgebung, Auswirkung, Prioritätsvorschlag, E-Mail-Adresse des Meldenden, Hinweis auf vorhandene Anhänge und einer Liste fehlender Informationen wie dem Zeitpunkt des ersten Auftretens oder konkreten Schritten zur Reproduktion.

Wichtig ist, dass die Ausgabe möglichst stabil und maschinenlesbar ist. Deshalb sollte man Copilot nicht einfach um eine freie Zusammenfassung bitten, sondern klare Vorgaben machen:

• Welche Felder müssen ausgefüllt werden?
• Welche Werte sind erlaubt?
• Wie wird zwischen Bug, Service Request und Frage unterschieden?
• Wann soll eine Information als unbekannt markiert werden?
• Welche Inhalte dürfen nicht erfunden werden?

Von der Copilot-Ausgabe zum Jira-Ticket

Nachdem Copilot die E-Mail analysiert hat, wird die strukturierte Ausgabe an die Jira-REST-API übergeben – vereinfacht ein POST-Aufruf an den Issue-Endpunkt, dessen Body Projektschlüssel, Vorgangstyp, Zusammenfassung, Beschreibung und Labels wie „email-import“ oder „copilot“ enthält.

Ein zentraler Grundsatz dabei: Fehlende Informationen sollen als fehlend gekennzeichnet werden. Copilot darf keine reproduzierbaren Schritte, Prioritäten oder technischen Ursachen erfinden, wenn sie aus der E-Mail nicht hervorgehen.

Für die Authentifizierung verwende ich ein technisches Konto beziehungsweise einen API-Zugang mit möglichst eingeschränkten Berechtigungen. Das Integrationskonto benötigt nur die Rechte, die für den vorgesehenen Prozess notwendig sind – beispielsweise das Erstellen von Issues und gegebenenfalls das Hinzufügen von Kommentaren oder Anhängen. Die konkrete Struktur hängt von der eingesetzten Jira-Version ab: Bei Jira Cloud und Jira Data Center können sich Authentifizierung, Endpunkte und Feldformate unterscheiden. Deshalb sollte die Integration zunächst in einem Testprojekt validiert werden.

Warum Jira Automation den Rest übernimmt

Ich habe bewusst nicht versucht, die gesamte Geschäftslogik in Copilot abzubilden. Copilot analysiert die E-Mail. Jira Automation setzt die verbindlichen Regeln um. Das ist aus meiner Sicht ein wichtiger Architekturgrundsatz: Künstliche Intelligenz eignet sich sehr gut für unstrukturierte Inhalte und sprachliche Interpretation. Für deterministische Regeln wie Zuständigkeiten, Komponenten oder Eskalationszeiten ist eine Workflow-Engine besser geeignet.

Nach dem Erstellen des Tickets kann Jira Automation zum Beispiel folgende Aktionen ausführen:

• Komponente anhand des betroffenen Systems setzen und das Ticket einem zuständigen Team zuweisen.
• Priorität anhand von Auswirkungen und Umgebung bestimmen und ein Service-Level-Ziel setzen.
• Labels ergänzen und ein übergeordnetes Epic oder einen Service Request verknüpfen.
• Das Support-Team benachrichtigen und eine Eingangsbestätigung an den ursprünglichen Absender senden.
• Bei fehlenden Pflichtinformationen einen Rückfragen-Status setzen.
• Bei bestimmten Kategorien automatisch einen Slack- oder Teams-Hinweis auslösen.

Ein Beispiel-Regelwerk

Ein vereinfachtes Regelwerk könnte so aussehen: Wenn Komponente = „Bestellprozess“ und Umgebung = „Produktion“ und Auswirkung = „Mehrere Benutzer betroffen“, dann Priorität = Hoch, Team = E-Commerce-Support, Assignee = zuständiger Bereitschaftsdienst, Label = production-impact. Für andere Komponenten greifen andere Regeln. Dadurch bleiben die Zuordnungen nachvollziehbar und zentral administrierbar.

Nicht jede E-Mail enthält genügend Informationen für eine sofortige Bearbeitung. Statt solche Nachrichten abzulehnen, erstellt der Prozess trotzdem ein Ticket und kennzeichnet fehlende Angaben. Jira Automation kann das Ticket beispielsweise im Status „Informationen benötigt“ anlegen, die fehlenden Angaben als Checkliste ergänzen, automatisch eine Rückfrage an den Absender senden und das Ticket nach Eingang der Antwort wieder in die Bearbeitung verschieben.

Eine automatische Antwort könnte lauten: „Vielen Dank für die Meldung. Wir haben daraus das Ticket SUP-1234 erstellt. Für die weitere Analyse benötigen wir noch die Schritte zur Reproduktion und den ungefähren Zeitpunkt, seit dem das Problem auftritt.“ So bleibt der Prozess für die Anwender einfach, ohne dass das Support-Team auf die notwendigen Informationen verzichten muss.

Fehlerbehandlung und Duplikate

Eine produktive Integration muss auch mit Fehlerfällen umgehen können. Zu den wichtigsten gehören:

• Jira ist nicht erreichbar: Die E-Mail darf nicht verloren gehen. Die Nachricht sollte in einer Warteschlange bleiben oder in einen Fehlerordner verschoben werden. Nach einer Wartezeit kann ein erneuter Versuch erfolgen.
• Die Copilot-Ausgabe ist unvollständig: Wenn Pflichtfelder fehlen oder die Antwort nicht dem erwarteten Schema entspricht, sollte kein unvollständiges Ticket entstehen. Stattdessen kann der Prozess die Nachricht zur manuellen Prüfung markieren, einen Fehler protokollieren oder ein Ticket mit dem Status „Manuelle Prüfung erforderlich“ anlegen.
• Das Ticket existiert bereits: Gerade bei Folgeantworten oder mehrfach weitergeleiteten E-Mails können Duplikate entstehen. Die Integration sollte eine eindeutige Kennung speichern – etwa die Message-ID der E-Mail, eine Kombination aus Betreff, Absender und Zeitstempel oder die Jira-Ticketnummer in der Antwort – und vor dem Erstellen prüfen, ob sie bereits verarbeitet wurde.
• Ein Ticket wird falsch kategorisiert: Auch eine gute Analyse kann sich irren. Kategorien und Zuweisungen sollten in Jira nachvollziehbar bleiben. Ein zusätzlicher Kommentar wie „Kategorisierung automatisch vorgenommen“ erleichtert die spätere Prüfung.

Datenschutz und Berechtigungen

E-Mails können personenbezogene Daten, interne Informationen oder vertrauliche Anhänge enthalten. Deshalb gehören Datenschutz und Zugriffskontrolle von Anfang an in das Konzept. Außerdem sollte klar dokumentiert werden, welche Inhalte analysiert werden und wie lange sie gespeichert bleiben.

• Nur relevante Postfächer und Nachrichten analysieren und den Zugriff auf das notwendige Postfach beschränken.
• API-Zugänge nicht fest im Code hinterlegen; Token sicher speichern und regelmäßig rotieren.
• Sensible Inhalte vor der Weitergabe prüfen.
• Protokolle so gestalten, dass keine unnötigen personenbezogenen Daten gespeichert werden.
• Rollen und Berechtigungen in Jira nach dem Least-Privilege-Prinzip vergeben.

Was ich bei der Umsetzung gelernt habe

Die wichtigste Erkenntnis war, dass die Qualität der Automatisierung nicht nur von Copilot abhängt. Entscheidend sind vor allem die Schnittstellen zwischen den einzelnen Komponenten.

• Klare Datenstruktur statt freier Texte: Je klarer das gewünschte Ausgabeformat definiert ist, desto zuverlässiger kann die API die Daten verarbeiten.
• KI und Regeln sinnvoll trennen: Copilot interpretiert den Inhalt, Jira Automation trifft verbindliche Workflow-Entscheidungen. Diese Trennung macht die Lösung stabiler und leichter zu warten.
• Ausnahmefälle von Anfang an einplanen: Nicht erreichbare APIs, fehlende Pflichtfelder, doppelte E-Mails und unklare Kategorien sind keine Sonderfälle, sondern Teil des normalen Betriebs.
• Transparenz ist wichtiger als Vollautomatisierung: Ein automatisch erstelltes Ticket sollte erkennbar sein. Kommentare, Labels oder ein eigenes Feld helfen, Herkunft und automatisch vorgenommene Aktionen nachzuvollziehen.
• Mit einem begrenzten Anwendungsfall starten: Besser ein klar abgegrenzter Pilot – zum Beispiel Bugs für ein bestimmtes Produkt oder Team – als sofort jedes Postfach zu automatisieren. Anschließend lassen sich Regeln, Prompt und Jira-Automationen anhand realer Fälle verbessern.

Fazit

Die Verbindung von Microsoft Copilot mit Jira über eine API löst ein alltägliches Problem: Bugs werden weiterhin per E-Mail gemeldet, obwohl der offizielle Prozess eigentlich über Jira laufen soll. Statt die Anwender zu einem neuen Verhalten zu zwingen, verbindet die Lösung beide Welten. Copilot analysiert den unstrukturierten E-Mail-Inhalt und erzeugt daraus strukturierte Daten. Die Jira-API legt das Ticket an. Jira Automation übernimmt anschließend die standardisierten Prozessschritte – von der Kategorisierung über die Priorisierung bis zur Zuweisung an die richtigen Personen.

Der entscheidende Erfolgsfaktor ist dabei nicht die maximale Automatisierung, sondern eine saubere Aufgabenteilung: Copilot versteht den Inhalt, die API verbindet die Systeme, Jira Automation setzt die Regeln um – und das Support-Team behält Kontrolle und Transparenz. So wird aus einer unstrukturierten Bug-E-Mail ein nachvollziehbarer, automatisierter und skalierbarer Supportprozess.