Vier ITSM-Wege für bestehende Prozesse
CentaurNexus bindet ServiceNow, Jira Service Management, Freshservice und Zendesk über reale Adapter an. Der konkrete Vorgang bleibt dem richtigen Tenant und Kundenkontext zugeordnet. Dadurch können Anfrage, Status, Entscheidung und Ergebnis ohne manuelles Kopieren zwischen Oberflächen verbunden werden.
Ausgehende Benachrichtigungen für Teams und Slack
Die Webhooks senden zunächst ausschließlich ausgehend. Der Ereigniskatalog umfasst Freigabeanfragen und Entscheidungen, Policy-Änderungen, neue Incidents, widerrufene Sitzungen und angenommene Einwilligungen. Welche Ereignisse ein Kanal tatsächlich erhält, wird pro Tenant und Kanal festgelegt.
Für den Alltag heißt das: Der Helpdesk sieht eine neue Freigabeanfrage, Security erhält den Hinweis auf eine Policy-Änderung, und der Betrieb wird bei einem neuen Incident oder einer widerrufenen Sitzung informiert. Die Nachricht enthält den zugehörigen Tenant, den Vorgangstyp, den aktuellen Status und einen direkten Weg in den passenden CentaurNexus-Kontext. So erreicht derselbe belastbare Sachstand die Teams, die ihn für ihre nächste Aufgabe benötigen.
Der Zielsystemstatus bleibt maßgeblich
Ein ITSM-Ticket oder eine Chatnachricht ist kein Beleg für die Wirkung einer Änderung. Bei schreibenden Abläufen bestätigt CentaurNexus den Erfolg erst nach Zielsystemwirkung und Read-back. Das ITSM-System erhält damit einen belastbaren Status statt nur die Meldung, dass ein API-Aufruf gestartet wurde.
MSP-Kontext nicht verlieren
Für MSPs bleibt der Zugriff auf tatsächlich verwaltete Tenants begrenzt. Ticket, Ereignis und Audit werden mit dem richtigen Mandantenkontext geführt. Verantwortlichkeit und Übergaben bleiben damit nachvollziehbar.
Welche Informationen in einen ITSM-Vorgang gehören
Eine Integration ist nur dann hilfreich, wenn sie mehr als einen Link übergibt. Ein sauberer Vorgang verbindet eine verständliche Zusammenfassung mit Tenant, Nutzer- oder Objektbezug, Quelle, aktuellem Status und der nächsten zuständigen Rolle. Technische Rohdaten werden nicht wahllos in das Ticket kopiert. Stattdessen erhält der Bearbeiter den für seine Aufgabe benötigten Kontext und einen kontrollierten Weg zurück zum vollständigen CentaurNexus-Vorgang.
Die externe Ticket-ID und die interne Vorgangs-ID bleiben miteinander verknüpft. Dadurch können Statusänderungen zugeordnet werden, ohne Kunden- oder Tenantkontexte zu vermischen. Der Auditpfad dokumentiert, welche Übergabe wann stattgefunden hat.
Ein Helpdesk-Ablauf von der Meldung bis zur Lösung
Ein Nutzer startet beispielsweise im Browser eine Anfrage zu einer blockierten Website. CentaurNexus ergänzt den erlaubten Nutzer-, Geräte- und Policy-Kontext. Das zuständige ITSM-System erhält daraus einen strukturierten Vorgang. Der Helpdesk sieht den Ausgangsbefund, kann fehlende Angaben ergänzen und entscheidet, ob der Fall gelöst, freigegeben oder an eine spezialisierte Rolle übergeben wird.
Wenn eine kontrollierte Änderung folgt, bleiben Ticket und technische Ausführung getrennte Zustände. Das Ticket kann anzeigen, dass die Aktivierung läuft. Erst nach bestätigtem Read-back wird der wirksame Zielzustand zurückgemeldet. Bei einem Fehler bleibt sichtbar, ob die Ursache im Entscheidungsweg, im Adapter, in der Aktivierung oder im Read-back liegt.
Benachrichtigungen ergänzen den Vorgang
Teams und Slack eignen sich für kurze Hinweise an die zuständige Gruppe. Eine Nachricht kann auf eine neue Entscheidung oder einen geänderten Status aufmerksam machen. Die vollständige Begründung, sensible Details und die verbindliche Aktion bleiben im dafür vorgesehenen CentaurNexus- oder ITSM-Kontext.
Technisch sendet CentaurNexus an eine vom Tenant eingerichtete Incoming-Webhook-Adresse des jeweiligen Dienstes. Aus Sicht von CentaurNexus ist der Datenfluss ausgehend. Kanal, Ereignisauswahl und Zieladresse gehören deshalb in die Tenant-Konfiguration und nicht in einen globalen, kundenübergreifenden Verteiler.
Verantwortung bei Ausfällen und Wiederholungen
Ein nicht erreichbares ITSM-System oder ein abgelehnter Webhook darf den eigentlichen Zscaler-Vorgang nicht fälschlich in Erfolg oder Misserfolg umdeuten. Die Integrationszustellung erhält einen eigenen Status. So kann die Plattform unterscheiden, ob die fachliche Aktion erfolgreich war und lediglich die Benachrichtigung noch aussteht.
Für die Abnahme werden auch Wiederholungen geprüft. Ein technischer Retry darf nicht unkontrolliert doppelte Tickets oder widersprüchliche Meldungen erzeugen. Idempotente Zuordnung, externe IDs und sichtbare Zustellzustände gehören daher zum Integrationsvertrag.
Unterschiedliche ITSM-Systeme, ein fachlicher Vertrag
ServiceNow, Jira Service Management, Freshservice und Zendesk besitzen unterschiedliche Objektmodelle, Berechtigungen und Statuslogiken. Der Adapter übersetzt diese Unterschiede in einen gemeinsamen CentaurNexus-Vorgang, ohne die Besonderheiten des Zielsystems zu ignorieren.
Ein Incident kann in einem System anders aufgebaut sein als ein Service Request in einem anderen. Deshalb wird je Kunde festgelegt, welcher Vorgangstyp für welchen CentaurNexus-Ablauf verwendet wird. Pflichtfelder, Anhänge, Kommentare und Abschlussstatus werden nicht pauschal gleichgesetzt.
Secrets und Zieladressen tenantgebunden verwalten
Zugangsdaten für ITSM-Adapter und Webhook-Adressen gehören nicht in öffentliche Websitekonfigurationen oder frei sichtbare Tickettexte. Sie werden zur Laufzeit aus dem vorgesehenen Secretpfad verwendet und bleiben dem Tenant zugeordnet. Logs und Fehlermeldungen dürfen die Werte nicht offenlegen.
Für Teams und Slack werden nur erlaubte HTTPS-Ziele akzeptiert. Eine Testnachricht prüft den Kanal, ohne bereits einen fachlichen Vorgang auszulösen. Änderungen an Zieladresse, Ereignisauswahl oder Aktivstatus werden nachvollziehbar verwaltet.
Datenschutz bei Übergaben
Nicht jedes technische Detail aus Nutzer-, Geräte- oder Feedkontext gehört in ein externes Ticket oder einen Chatkanal. Das Mapping definiert, welche Felder für den Zweck erforderlich sind. Tieferer Kontext bleibt in CentaurNexus und wird über einen berechtigten Link geöffnet.
Bei internationalen Organisationen werden außerdem Region, Sprache und Empfängerkreis geprüft. Eine Benachrichtigung soll den richtigen Bearbeiter erreichen, ohne sensible Inhalte unnötig in breiten Teamkanälen zu verteilen.
Betriebsverantwortung bleibt sichtbar
Die Integration verbindet Systeme, verschiebt aber nicht unbemerkt die Verantwortung. Das ITSM-Team verantwortet seine Formulare, Queues und Statuslogik. Der CentaurNexus-Administrator verantwortet Tenantmapping, Rollen und Adapterkonfiguration. Die fachliche Entscheidung bleibt bei der im Workflow vorgesehenen Rolle.
Für jeden Adapter werden technische und fachliche Ansprechpartner festgelegt. Bei einer Störung ist dadurch erkennbar, ob das Problem den CentaurNexus-Vorgang, die externe API, die Berechtigung oder den Zielkanal betrifft.
Was ein tägliches Integrationsreview prüft
Der Betrieb kontrolliert fehlgeschlagene Zustellungen, ungewöhnlich lange offene Übergaben, nicht zugeordnete externe IDs und Kanäle mit wiederholten Fehlern. Dabei wird fachlicher Vorgangsstatus von technischem Zustellstatus getrennt.
Ein kurzes Review verhindert, dass eine erfolgreiche Zielsystemänderung wegen einer ausgebliebenen Nachricht übersehen wird oder ein geschlossenes Ticket eine noch offene technische Wirkung verdeckt.
Einführung in sieben Schritten
- Führendes ITSM-System und konkrete Vorgangstypen je Tenant festlegen.
- Felder, Statuswerte, Rollen und Verantwortungsgrenzen zuordnen.
- Authentifizierung und erforderliche Rechte mit geringstmöglichem Umfang einrichten.
- Tenant- und Kundenzuordnung in beiden Richtungen testen.
- Teams- oder Slack-Kanäle mit ausgewählten Ereignissen konfigurieren.
- Erfolgs-, Fehler- und Wiederholungsfälle kontrolliert abnehmen.
- Read-back und finalen Ticketstatus gemeinsam prüfen.
Das Ziel ist kein zusätzliches Parallelportal. CentaurNexus verbindet den technischen Zscaler-Kontext mit dem Arbeitsort, an dem Support und Betrieb ihre Aufgaben bereits steuern.
Häufige Fragen
Welche ITSM-Systeme werden angebunden?
ServiceNow, Jira Service Management, Freshservice und Zendesk.
Quellen und weiterführende Informationen
Den Arbeitsablauf im Kontext ansehen
Wählen Sie im Demo-Launcher die passende Rolle. Die Demo verwendet vorbereitete Beispieldaten.
Demo-Launcher öffnen