Neuerungen in HaloITSM – 2026, zweite Version

Die zweite Version des Jahres 2026 bringt eine Vielzahl von Verbesserungen in den Bereichen Zugriffskontrolle, Genehmigungen, Automatisierung, Berichterstellung und im Self-Service-Portal mit sich. Im Mittelpunkt dieser Version stehen die Erweiterung der Kontrollmöglichkeiten für Administratoren, die Steigerung der täglichen Effizienz für Agenten sowie die einfachere Anpassung von HaloITSM an die Arbeitsabläufe Ihres Unternehmens.

‍

Neue Integrationen mit AssetBots und SailPoint IdentityNow erweitern die Reichweite von HaloITSM in Ihrem gesamten Technologie-Ökosystem. Schauen wir uns die Neuerungen einmal genauer an.

‍

KI-Fähigkeiten und Automatisierung

Diese Version bringt eine erhebliche Erweiterung der KI-Fähigkeiten von HaloITSM mit sich und umfasst neue Möglichkeiten zur Automatisierung und Gewinnung von Erkenntnissen mithilfe von KI auf der gesamten Plattform.

‍

Wir stellen „AI Ability“ vor: Ein benutzerdefinierter Satz von Anweisungen, der an eine KI gesendet wird, um eine Antwort zu generieren, kann nun direkt in Integrations-Runbooks verwendet werden. Um einem Runbook eine „AI Ability“ hinzuzufügen, legen Sie den Aktionstyp eines Schritts auf „AI Ability“ fest. In den Anweisungen kann auf Eingabevariablen verwiesen werden, und die Antwort der KI kann zum Ausfüllen von Ausgabevariablen verwendet werden, sodass die von der KI generierte Antwort plattformweit genutzt werden kann. Außerdem steht ein Kontrollkästchen zur Verfügung, mit dem die Ausgabe der KI zwangsweise im JSON-Format festgelegt werden kann, wodurch mehrere Runbook-Variablen aus einer einzigen Antwort ausgefüllt werden können.

‍

‍

Zudem werden KI-Agenten eingeführt, die ebenfalls über Integrations-Runbooks ausgelöst werden können, indem in einem Runbook-Schritt der Aktionstyp „KI-Agent“ ausgewählt wird. KI-Agenten sind so konfiguriert, dass sie in HaloITSM automatisch eine Reihe von Aufgaben auf der Grundlage einer Reihe von Anweisungen ausführen, und haben Zugriff auf dieselben Halo-Funktionen, die über den MCP-Server verfügbar sind, darunter das Abrufen von Ticketdaten, die Suche in der Wissensdatenbank und das Hinzufügen von Aktionen zu Tickets. Bei der Konfiguration eines KI-Agenten muss eine Halo-Anwendung ausgewählt werden, über die die Autorisierung erfolgt; diese bestimmt die Identität und die Berechtigungen des Agenten. Wie bei KI-Fähigkeiten können Eingabevariablen aus dem Runbook in die Anweisungen des Agenten übergeben werden, und die Antwort des Agenten kann Ausgabevariablen füllen.

‍

‍

Wenn das System mithilfe von KI ein Ticket, eine Aktion oder einen KB-Artikel erstellt, wird nun zu Berichtszwecken ein Kennzeichen in der Datenbank gespeichert. Die entsprechenden Feldnamen lauten „faicreated“, „aacreated“ und „kbaicreated“ und können über die API mithilfe der Eigenschaft „ai_created“ festgelegt werden. Die ID des virtuellen Agenten, des KI-Agenten oder der MCP-Tool-Sammlung, die zur Erstellung der Entität verwendet wurde, wird ebenfalls erfasst und korreliert mit der ID in der Tabelle „VirtualAgent“.

‍

Zu guter Letzt kann nun unter „Konfiguration > KI“ die Ticket-Clusterung aktiviert werden, um ähnliche Tickets anhand ihrer Embeddings automatisch zu gruppieren. Dies hilft dabei, die häufigsten Ticket-Typen zu identifizieren, das Volumen pro Cluster zu verfolgen und neue schwerwiegende Vorfälle sofort zu erkennen, sobald sie auftreten. Jeder Cluster erhält eine von der KI generierte Beschreibung und Lösungsvorschlag. Über die Registerkarte „Cluster Matched Tickets“ können zudem weitere Tickets angezeigt werden, die dem aktuell angezeigten Ticket zum selben Cluster gehören. Frühere Clustering-Durchläufe werden in der Datenbank archiviert, sodass Sie über den Cluster-Endpunkt der API Berichte zu Veränderungen des Clustervolumens im Zeitverlauf erstellen können.

‍

‍

‍

Verbesserungen bei Benutzeroberfläche und Benutzerfreundlichkeit

Darüber hinaus wurden in dieser Version eine Reihe von Verbesserungen hinsichtlich der Benutzeroberfläche und der Benutzerfreundlichkeit vorgenommen.

‍

Unter „Erweiterte Einstellungen“ kann nun ein benutzerdefiniertes Hilfemenü aktiviert werden. Sobald diese Option aktiviert ist, können Sie über eine Konfigurationstabelle die Standardoptionen des System-Hilfemenüs ändern oder deaktivieren, indem Sie deren Bezeichnungen und Links bearbeiten sowie eigene Einträge hinzufügen, beispielsweise einen direkten Link zu Ihrem internen Konfigurations-Tracking oder Ihrer Wissensdatenbank.

‍

‍

Zudem unterstützen benutzerdefinierte Felder nun eine neue Option namens „Hover“ für die Einstellung „Anzeigetyp der Hilfe“. Ist diese Option ausgewählt, wird die Feldhilfe nur angezeigt, wenn der Benutzer mit der Maus über das Fragezeichen-Symbol neben dem Feld fährt. So bleiben die Formulare übersichtlicher, ohne dass nützliche Hinweise vollständig ausgeblendet werden.

‍

‍

Drittens wurde ein neuer Benachrichtigungstyp „Live-Chat-Benachrichtigung“ sowie ein neuer Ereignisauslöser „Neue Live-Chat-Anfrage (vom Benutzer)“ hinzugefügt, sodass Agenten Browser-Benachrichtigungen erhalten, wenn eine neue Live-Chat-Anfrage von einem Benutzer eingeht.

‍

‍

Schließlich wurde auch das Gantt-Diagramm aktualisiert und bietet nun eine verbesserte Darstellung in den Ansichten „Ticket“, „Agent“ und „Projekt“.

‍

‍

‍

Parallele Genehmigungen und risikobasierte Genehmigungswege

Genehmigungsschritte können nun so konfiguriert werden, dass sie parallel ablaufen, indem man sie zu Gruppen zusammenfasst. Jeder Schritt kann als eigenständiger Schritt, als Hauptschritt einer Gruppe oder als Teil einer Gruppe festgelegt werden.

‍

‍

Wenn Schritte zur selben Gruppe gehören, werden sie alle gleichzeitig gestartet, sobald der Genehmigungsprozess den Hauptschritt der Gruppe erreicht. Schritte innerhalb einer Gruppe übernehmen bestimmte Konfigurationen vom Hauptschritt, darunter Benachrichtigungen über Ergebnisse und Statusänderungen. Das bedeutet, dass alle Schritte einer Gruppe in einer sequenziellen Reihenfolge angeordnet sein müssen, wobei der Hauptschritt der Gruppe an erster Stelle stehen muss.

‍

Der Prozess wird abgelehnt, wenn ein Schritt innerhalb der Gruppe seinen Ablehnungsschwellenwert erreicht, und genehmigt, sobald alle Schritte ihre Genehmigungsschwellenwerte erreicht haben.

‍

‍

Zudem steht der Risikowert nun als Kriterium bei der Konfiguration von Regeln für Genehmigungsprozesse zur Verfügung, sodass Genehmigungen auf der Grundlage des berechneten Risikograds eines Tickets weitergeleitet werden können.

‍

‍

Erweiterte Filterung der Ticketliste mit „Oder“-Logik

Wenn unter „Tickets > Allgemeine Einstellungen“ die Option „Dynamische Filter für die Ticketliste aktivieren“ aktiviert ist, steht nun auch die neue Option „Gruppen für dynamische Filter verwenden“ zur Verfügung.

‍

Durch Aktivieren dieser Option wird das Verhalten des dynamischen Filters so geändert, dass Filter in Gruppen von bis zu drei Elementen organisiert werden können. Die Kriterien innerhalb einer Gruppe werden als logisches UND angewendet, während die einzelnen Gruppen untereinander als logisches ODER verglichen werden.

‍

‍

Dadurch lassen sich differenziertere Filterkombinationen erstellen. So können Sie beispielsweise mit einem einzigen gespeicherten Filter alle Tickets finden, die einem bestimmten Bearbeiter zugewiesen sind, oder alle neuen, noch nicht zugewiesenen Tickets.

‍

‍

Workflow-Automatisierung und -Ablaufsteuerung

Beim Hinzufügen eines Workflow-Schritts gibt es nun die Option „Phase automatisch erstellen“. Die Phase erhält denselben Namen wie der Schritt und wird automatisch aktualisiert, wenn sich der Name des Schritts ändert. So bleiben Workflow-Phasen und -Schritte ohne manuellen Aufwand synchron.

‍

‍

„Genehmigungsprozess starten“ steht nun auch als Option für Workflow-Automatisierungen zur Verfügung, sodass Genehmigungsprozesse ohne zusätzliche Konfiguration direkt aus einem Workflow-Schritt heraus ausgelöst werden können.

‍

‍

Zudem können Automatisierungen in Workflows eine Sequenznummer zwischen 0 und 10 zugewiesen werden. Alle Automatisierungen mit demselben Sequenzwert werden gemeinsam in die Warteschlange gestellt, wobei die Verarbeitung mit dem niedrigsten Wert beginnt. Auf diese Weise lässt sich die Ausführungsreihenfolge steuern, wenn eine Automatisierung vom Ergebnis einer anderen abhängt oder wenn zwei Automatisierungen andernfalls versuchen könnten, dieselben Daten gleichzeitig zu aktualisieren.

‍

‍

Erweiterte rollenbasierte Zugriffskontrolle

Mit dieser Version wird die rollenbasierte Zugriffskontrolle auf mehrere weitere Bereiche der Plattform ausgeweitet, wodurch Administratoren genauer steuern können, wer wichtige Konfigurationen einsehen und verwalten darf.

‍

Die Regeln für das Ereignismanagement können nun nach Agentenrolle, einzelner Agenten oder Team eingeschränkt werden, wodurch unbeabsichtigte Änderungen an den Regeln verhindert werden, die die automatisierte Ereignisbearbeitung steuern. Dies ist besonders wichtig für Unternehmen, die ereignisgesteuerte Automatisierungen in großem Maßstab einsetzen.  

‍

Ebenso können benutzerdefinierte Felder für Agenten im Bereich „Meine Einstellungen“ nun je nach Agentenrolle oder für einzelne Agenten eingeschränkt werden, sodass Felder, die internen Verwaltungszwecken dienen, für allgemeine Agenten nicht sichtbar sind.

‍

Nicht zuletzt wurde in dieser Version die Zugriffskontrolle auch auf die Active-Directory-Konfiguration und auf Genehmigungsgruppen ausgeweitet, sodass Administratoren nun steuern können, wer diese Bereiche innerhalb von HaloITSM einsehen und verwalten darf.

‍

‍

‍

Erweiterungen des Self-Service-Portals

In diesem Quartal wurden mehrere Verbesserungen an der Benutzererfahrung des Self-Service-Portals vorgenommen.

‍

Wenn in einem Spaltenprofil die Option „Untergeordnete Tickets einbeziehen“ aktiviert ist, werden untergeordnete Tickets nun in der Ansicht „Meine Tickets“ des Portals unter ihrem übergeordneten Ticket zusammengefasst, wodurch Benutzer einen übersichtlicheren und besser strukturierten Überblick über die zugehörigen Aufgaben erhalten. Das für untergeordnete Tickets zu verwendende Spaltenprofil wird auf der Registerkarte „Einstellungen“ des jeweiligen Ticket-Typs konfiguriert.

‍

‍

Es ist nun auch möglich, zusätzliche Benutzerinformationen anzuzeigen, wenn ein Benutzer über das Portal ein neues Ticket erstellt. Mit zwei neuen Einstellungen auf Ticket-Typ-Ebene – „Zusätzliche Benutzerdetails bei der Erstellung neuer Tickets anzeigen“ und „Benutzerdetailfelder“ – können Sie festlegen, welche Benutzerfelder unterhalb des Kontaktbereichs im Formular für neue Tickets angezeigt werden sollen, darunter sowohl Standard- als auch benutzerdefinierte Benutzerfelder. Die Anzeigereihenfolge wird durch die Eigenschaft „Sequenz“ gesteuert.

‍

‍

Darüber hinaus unterstützt der Servicekatalog nun zwei neue optionale Kategorien: die 10 zuletzt vom Benutzer aufgerufenen Dienste sowie die 10 beliebtesten Dienste. Beide können über die Konfigurationseinstellungen für Dienste aktiviert werden. Dort können Dienste aus den Favoriten ausgeschlossen werden, wenn sie auch aus diesen Kategorien ausgeschlossen sind.

‍

‍

In den Einstellungen des Self-Service-Portals steht nun die neue Option „Anhänge in einem eigenen Reiter in den Ticketdetails anzeigen“ zur Verfügung, mit der Anhänge für Portalbenutzer in einem eigenen Reiter in der Ticketdetailansicht angezeigt werden können.

‍

‍

Protokolltickets direkt aus den Anlagenstammsätzen erfassen

Es ist nun möglich, für ein Konfigurationselement oder einen Asset-Typ einen Standard-Ticket-Typ festzulegen, um ein Ticket direkt aus einem Asset-Datensatz im Self-Service-Portal zu erstellen. Dadurch können Benutzer Probleme oder Anfragen im Zusammenhang mit einem bestimmten Asset schneller melden, ohne die Seite verlassen und die Asset-Details manuell erneut eingeben zu müssen.

‍

‍

‍

Schnellere Berichterstellung zu Assets und durchgesetzte Berechtigungen für Wissensdatenbankartikel im Query Builder

Die Leistung bei der Abfrage von Asset-Feldern im Query Builder wurde verbessert, wodurch sich die Ladezeiten beim Erstellen von Berichten für große Asset-Datensätze verkürzt haben. Zudem wurde die Durchsetzung von Artikelberechtigungen hinzugefügt. Ist diese Funktion aktiviert, beschränkt jeder Query-Builder-Bericht zu KB-Artikeln die Ergebnisse automatisch auf jene Artikel, für die der ausführende Benutzer eine Anzeigeberechtigung besitzt. Dadurch wird sichergestellt, dass die Berichtsausgaben die bestehenden Zugriffskontrollen der Wissensdatenbank einhalten.

‍

‍

‍

Überprüfung der Sicherheitsfrage bei der Anrufbearbeitung

Unter „Benutzerkonfiguration“ steht nun ein neues Modul „Sicherheitsfragen“ zur Verfügung, mit dem Sie Fragen zur Identitätsprüfung für Benutzer einrichten können, die sich beim Service Desk melden.  

‍

Sie können die Fragen konfigurieren, die die Benutzer beantworten müssen, und dabei optional eine Überprüfung hinsichtlich Mindestlänge, Höchstlänge und regulären Ausdrücken vornehmen. Die Anzahl der gestellten Fragen (bis zu fünf) sowie die Schwellenwerte für „bestanden“ und „nicht bestanden“ lassen sich konfigurieren, indem Sie die Anzahl der richtig zu beantwortenden Fragen und die Anzahl der zulässigen falschen Antworten festlegen.

‍

‍

Benutzer, die ihre Antworten noch nicht festgelegt haben, werden im Portal dazu aufgefordert und können diese jederzeit auf der Seite „Einstellungen“ aktualisieren. Dabei stehen ihnen zusätzliche Sicherheitsmaßnahmen zur Verfügung, um festzulegen, ob die Antworten als Klartext angezeigt oder wie Passwörter maskiert werden sollen.

Sobald auf dem Anrufbildschirm ein Benutzer ausgewählt wurde, kann der Mitarbeiter eine Überprüfung anhand von Sicherheitsfragen einleiten. Der Benutzer gibt seine Antworten mündlich an, und der Mitarbeiter überprüft diese in Echtzeit. Wenn die Überprüfung erfolgreich ist, wird der Benutzer dem Anruf zugeordnet.

‍

‍

‍

OLA-Meldungen zu Datenschutzverletzungen

Es ist nun möglich, Benachrichtigungen auszulösen, wenn OLAs festgelegte Schwellenwerte erreichen; dies funktioniert ähnlich wie das bestehende SLA-Benachrichtigungssystem.

‍

Unter „Konfiguration“ > „Service Level Agreements“ > „Allgemeine Einstellungen“ können bis zu drei separate OLA-Benachrichtigungsschwellenwerte definiert werden. Diese können als Prozentsatz der verstrichenen OLA-Zeit oder als Anzahl der verbleibenden Arbeitsstunden festgelegt werden.

‍

‍

Nach der Konfiguration können Benachrichtigungen, Webhooks oder Runbook-Ereignisse ausgelöst werden, sobald der jeweilige Schwellenwert erreicht wird.

‍

‍

Die Auslösezeitpunkte für Benachrichtigungen werden automatisch neu berechnet, wenn eine OLA angehalten und wieder fortgesetzt wird, sodass sie während des gesamten Ticket-Lebenszyklus korrekt bleiben.

‍

‍

Verbesserungen bei der Runbook-Diagnose und bei Triggern

In dieser Version wurden drei Verbesserungen an der Benutzererfahrung des Integrations-Runbooks vorgenommen.

‍

In den Schritten des Integrations-Runbooks steht nun eine neue Schaltfläche zur Verfügung, mit der Sie das Anfrage- und Antwortprotokoll für diesen bestimmten Schritt direkt innerhalb der Plattform einsehen können. Dadurch lassen sich Probleme bei API-gesteuerten Automatisierungen deutlich schneller diagnostizieren, ohne dass Sie auf externe Tools zurückgreifen müssen.

‍

‍

Die „Ticket-Typ-Gruppe“ steht nun als Bedingung für die Auslösung von Benachrichtigungen und Runbooks zur Verfügung und erweitert damit die Flexibilität der Automatisierungslogik für Unternehmen, die ihre Dienste anhand von Ticket-Typ-Gruppierungen strukturieren.

‍

‍

‍

Schließlich werden die „End (Success)“-Schritte im Runbook-Flussdiagramm-Designer nun grün angezeigt, sodass sich erfolgreich abgeschlossene Abläufe auf einen Blick leichter von anderen Schrittarten unterscheiden lassen.

‍

‍

‍

Benutzerdefiniertes Feld für Anhänge in Tickets

Bei der Konfiguration benutzerdefinierter Felder für Tickets steht nun ein neuer Feldtyp „Anhang“ zur Verfügung. Dazu müssen clientseitige Uploads aktiviert sein.

‍

Wird das Feld einem Ticket-Typ hinzugefügt, wird es beim Erstellen eines neuen Tickets im Portal als Drag-and-Drop-Bereich angezeigt und unterstützt das Hochladen mehrerer Dateien. Sobald das Ticket erstellt wurde, wird das Feld schreibgeschützt und zeigt anklickbare Dateilinks an. Über dieses Feld hinzugefügte Anhänge erscheinen ebenfalls auf der Registerkarte „Anhänge“ des Tickets und können von dort aus verwaltet werden, einschließlich der dauerhaften Löschung.

‍

‍

‍

Geplante Berichte an Verteilerlisten senden

Bei der Konfiguration der Empfänger für einen geplanten Bericht steht nun eine neue Option „Empfängertyp“ zur Verfügung. Wenn Sie von „Manuell“ auf „Verteilerliste“ umschalten, können Sie eine vorhandene Verteilerliste als Empfänger auswählen, sodass Sie nicht mehr für jeden Bericht die einzelnen E-Mail-Adressen pflegen müssen, wenn sich die Zusammensetzung des Teams ändert.

‍

‍

‍

Integrationen

‍

Sailpoint-Integration

‍

AssetBots

‍

‍

Möchten Sie mehr erfahren?

‍

Für weitere Informationen und um alle neuen Funktionen anzuzeigen, klicken Sie auf das Fragezeichen oben rechts auf Ihrem Bildschirm und wählen Sie anschließend „Versionsdetails anzeigen“ aus.

‍

‍

Weitere Informationen zu zukünftigen Entwicklungen finden Sie hier in unserer Roadmap!

Wenn Sie mit einem unserer Mitarbeiter über bestimmte Funktionen sprechen möchten oder weitere konkrete Fragen haben, wenden Sie sich bitte an Ihren Customer Success Manager oder kontaktieren Sie uns einfach – wir melden uns dann so schnell wie möglich bei Ihnen.

‍