Neuerungen in HaloPSA – 2026, zweite Version
Entdecken Sie alle wichtigen neuen Funktionen und Verbesserungen, die in Version 2.236 von HaloPSA veröffentlicht wurden.
Entdecken Sie alle wichtigen neuen Funktionen und Verbesserungen, die in Version 2.236 von HaloPSA veröffentlicht wurden.
Die zweite Version von HaloPSA für das Jahr 2026 bietet eine Vielzahl neuer Verbesserungen in den Bereichen E-Mail-Kampagnen, agentenbasierte KI, Automatisierung, Berichterstellung, Projekte, Anrufbearbeitung und Kundenkommunikation.
Im Mittelpunkt dieser Version steht das Ziel, MSPs die Automatisierung von Kundenprozessen, die Erstellung leistungsfähigerer KI-gestützter Workflows, die Verbesserung der Transparenz im gesamten Betrieb sowie die Verwaltung der Servicebereitstellung über eine einzige vernetzte Plattform zu erleichtern. Von E-Mail-Kampagnen im Workflow-Stil und Verbindungen zu externen MCP-Servern bis hin zu verbesserten Gantt-Diagrammen, geplanten Berichten, der Abrechnung von Fahrtkosten und der neuen Integration des Intermedia Contact Centre gibt es für MSP-Teams viel zu entdecken.
Schauen wir uns einmal genauer an, was es Neues bei HaloPSA gibt.
E-Mail-Kampagnen in HaloPSA unterstützen nun einen neuen Kampagnen-Generator im Workflow-Stil, der Teams mehr Flexibilität bei der Erstellung von Kunden-, Lead- und Opportunity-Journeys bietet.
Bisher konnten Nutzer bei geplanten Kampagnen E-Mails konfigurieren und bestimmte Datums- und Zeitangaben für deren Versand festlegen. Diese Funktion steht weiterhin zur Verfügung, doch der neue Workflow-Ansatz bietet einen visuelleren, auf der Customer Journey basierenden Ansatz.
Beim Erstellen einer Kampagne können Nutzer nun zwischen dem bisherigen Zeitplan-Modus und dem neuen Workflow-Modus wählen. Bei Kampagnen im Workflow-Modus werden mithilfe des Workflow-Editors Abläufe für Kontakte, Kunden, Leads und Verkaufschancen erstellt.

Für Kampagnen im Workflow-Stil stehen alle Kampagnentypen zur Verfügung, darunter „Blast“-Kampagnen, „Nurture Triggered“-Kampagnen und „Nurture Scheduled“-Kampagnen. Dadurch erhalten Teams mehr Kontrolle darüber, wie die Kommunikation strukturiert wird – ganz gleich, ob sie einmalige Updates versenden oder längere Nurture-Sequenzen aufbauen.

Kampagnen im Workflow-Stil werden aus vier Schrittarten aufgebaut: „Aktion“, „Kommunikation“, „Aufteilung“ und „Ende“. Bei jedem Schritt wird zudem die Anzahl der Kontakte oder Leads angezeigt, die sich derzeit in dieser Phase befinden, wodurch sich leichter nachvollziehen lässt, wie sich die Teilnehmer durch die Kampagne bewegen.
Mithilfe von Aktionsschritten können Teams eine Aktion auswählen, die im Rahmen der Kampagnenabfolge ausgeführt werden soll. Zum Start steht hierfür eine Verzögerungsaktion zur Verfügung; weitere Optionen sind für die Zukunft geplant. Zu diesen zukünftigen Aktionen gehören die Aktualisierung von Kontakt- oder Lead-Daten, das Initiieren benutzerdefinierter Integrationen, das Ausführen von Runbooks und das Auslösen von Webhooks.
Die Kommunikationsschritte unterstützen derzeit E-Mails; weitere Kommunikationskanäle werden in Kürze hinzukommen. Jeder E-Mail-Schritt umfasst Leistungskennzahlen wie die Gesamtzahl der versendeten E-Mails, die Öffnungsrate, die Klickrate und die Abmelderate. Bei der Auswertung von Öffnungen und Klicks werden auch E-Mail-Sicherheitstools berücksichtigt, wodurch Teams ein klareres Bild vom tatsächlichen Engagement erhalten.

Mit Split-Schritten können Teams ihre Kampagnenzielgruppen anhand konfigurierbarer Filter aufteilen. Dabei kommen dieselben Filter wie bei Verteilerlisten zum Einsatz, wobei gruppierte „oder“-Bedingungen unterstützt werden. Jeder Split-Schritt erzeugt zwei Pfade: einen für Kontakte oder Leads, bei denen die Bedingung erfüllt ist, und einen für diejenigen, bei denen sie nicht erfüllt ist.
Dadurch lassen sich gezieltere Customer Journeys erstellen. So könnte eine Kampagne beispielsweise eine erste E-Mail versenden, sieben Tage warten, die Zielgruppe anhand des Engagements oder anderer Kriterien aufteilen, an jede Gruppe unterschiedliche Folge-E-Mails senden, weitere zehn Tage warten und schließlich eine abschließende E-Mail versenden, bevor die Kampagne beendet wird.

Live-Workflows können auch nach dem Start einer Kampagne bearbeitet werden. Dabei gibt es einige Sicherheitsvorkehrungen, beispielsweise wird verhindert, dass Benutzer einen Schritt löschen können, wenn sich derzeit Kontakte oder Leads in diesem Schritt befinden.
Kampagnen können je nach Anwendungsfall abgeschlossen, abgebrochen oder beendet werden. Der Abschluss einer Kampagne bedeutet, dass alle Nutzer oder Leads den letzten Schritt erreicht haben. Durch das Abbrechen werden alle Nutzer gestoppt, neue Einträge verhindert und E-Mails in der Warteschlange storniert. Bei Nurture-Kampagnen ermöglicht das Beenden der Kampagne bestehenden Nutzern die Fortsetzung, während neue Einträge verhindert werden.
Das Hilfe-Menü in HaloPSA lässt sich nun individuell anpassen, sodass Teams die Einträge, Bezeichnungen und Link-Typen konfigurieren können, die den Benutzern angezeigt werden.
Diese Funktion kann unter „Konfiguration > Erweiterte Einstellungen“ aktiviert werden. Nach der Aktivierung können Organisationen das Hilfe-Menü so anpassen, dass es ihre eigenen internen Ressourcen, Support-Inhalte oder wichtige Links besser widerspiegelt.


Dadurch erhalten Teams mehr Kontrolle über das Support-Erlebnis innerhalb von HaloPSA, sodass sie Agenten oder Endbenutzer leichter auf die relevantesten Anleitungen hinweisen können.

Mit dieser Version werden neue Funktionen der agentenbasierten KI eingeführt, darunter die Unterstützung für Verbindungen zu externen MCP-Servern.
Über externe MCP-Server kann HaloPSA eine Verbindung zu anderen Plattformen herstellen, sodass KI-Agenten Skripte ausführen, Konten aktualisieren oder wichtige Informationen aus externen Systemen abrufen können.
Benutzer können einen benutzerdefinierten Header und einen API-Schlüssel eingeben, um eine Verbindung zu einem externen MCP-Server herzustellen. Die Liste der externen MCP-Server ist unter „Konfiguration > KI“ gespeichert.


Externe MCP-Server können dann von einem KI-Agenten aufgerufen werden. KI-Agenten werden unter „Konfiguration > KI“ über die Schaltfläche „KI-Agenten“ erstellt.
Bei der Erstellung eines KI-Agenten wählen die Benutzer eine Halo-Anwendung aus, mit der sich der Agent autorisieren soll. Dadurch werden die Identität und die Berechtigungen des Agenten festgelegt, sodass sichergestellt ist, dass der Agent nur Zugriff auf die entsprechenden Bereiche des Systems hat.
Für den KI-Agenten können Anweisungen konfiguriert und Eingabevariablen hinzugefügt werden, sodass Werte aus einem Runbook übergeben werden können. Sobald der Agent seine Aufgabe abgeschlossen hat, sendet er eine Antwort zurück, die zum Ausfüllen von Ausgabevariablen verwendet werden kann.
Ein einzelner AI-Agent-Anruf kann bis zu fünf Minuten dauern.



KI-Agenten können neben externen MCP-Tools auch Halo-MCP-Tools verwenden. Die für den Agenten verfügbaren Halo-Tools lassen sich auf der Registerkarte „Funktionen“ konfigurieren.

KI-Agenten können nun direkt in Runbooks verwendet werden.
Bei der Konfiguration eines Runbook-Schritts können Benutzer den Aktionstyp „AI Agent“ auswählen. Dadurch kann das Runbook die für diesen Agenten verfügbaren MCPs aufrufen und die bereits für den AI Agent konfigurierten Anweisungen verwenden.

Die in den Anweisungen des KI-Agenten aufgeführten Variablen können je nach Kontext der Automatisierung in jedem Schritt des Runbooks aktualisiert werden. Dadurch kann derselbe KI-Agent in verschiedenen Workflows wiederverwendet werden und erhält dennoch zum richtigen Zeitpunkt im Prozess die richtigen Daten.

Jeder Runbook-Schritt, der einen KI-Agenten verwendet, kann die Anweisungsvariablen mithilfe von Variablen auf Runbook-Ebene definieren. Diese werden in die Wertespalte eingegeben, sodass im Verlauf der Automatisierung Informationen aus dem Runbook an den KI-Agenten übergeben werden können.

Dies bietet MSPs mehr Flexibilität bei der Erstellung von Automatisierungen, die mit anderen Plattformen interagieren, Informationen abrufen oder Entscheidungen auf der Grundlage von Echtzeitdaten treffen müssen.
KI-Fähigkeiten können nun unter „Konfiguration > KI“ über die Schaltfläche „KI-Fähigkeiten“ erstellt werden.

Mit den KI-Funktionen lassen sich API-Aufrufe an die KI einfacher konfigurieren. Bisher musste jede an das KI-Modell gesendete Anweisung die korrekte JSON-Struktur enthalten, die je nach verwendetem Modell variieren konnte.
Die neue Methode vereinfacht diesen Vorgang. Die Nutzer können die Eingabeaufforderung hinzufügen, ein Modell auswählen und je nach Anwendungsfall entscheiden, ob die Antwort im JSON-Format zurückgegeben werden soll.

Variablennamen können auch in den Anweisungen verwendet und aus vorherigen Runbook-Schritten übernommen werden. Dadurch lassen sich KI-Funktionen leichter in verschiedenen Automatisierungen und Workflows wiederverwenden.
HaloPSA protokolliert nun, wann bestimmte Entitäten von der KI erstellt wurden.
Wenn das System mithilfe von KI ein Ticket, eine Maßnahme oder einen Knowledge-Base-Artikel erstellt, wird dies in der Datenbank für Berichtszwecke gekennzeichnet. Die entsprechenden Feldnamen lauten faicreated, aacreated und kbaicreated.
Diese können auch über die API mithilfe der ai_created Eigenschaft.
Die ID des virtuellen Agenten, des KI-Agenten oder der MCP-Tool-Sammlung, die zur Erstellung der Entität verwendet wurde, wird ebenfalls erfasst. Diese entspricht der ID in der Tabelle „VirtualAgent“, wodurch die Teams einen besseren Überblick darüber erhalten, woher die KI-generierten Datensätze stammen.

Es stehen nun neue MCP- und Virtual-Agent-Funktionen zum Abrufen von Benutzern und Assets zur Verfügung.
In der MCP-Serverkonfiguration sowie bei den Virtual- und Operations-Agents stehen vier neue Funktionen zur Auswahl:
Assets suchen, ein Asset abrufen, Benutzer suchen und einen Benutzer abrufen.
Die Benutzerfunktionen stehen nur Agenten zur Verfügung, beispielsweise über Operations-Agenten oder von Agenten autorisierte MCP-Aufrufe. Die Asset-Funktionen stehen sowohl Agenten als auch Benutzern zur Verfügung.

Dadurch erhalten KI-Agenten und mit dem MCP verbundene Workflows mehr Kontext, wenn sie in HaloPSA mit Benutzer- und Asset-Daten arbeiten.
Die Ticket-Gruppierung kann nun unter „Konfiguration > KI“ aktiviert werden.
Diese Funktion gruppiert ähnliche Tickets automatisch anhand ihrer KI-generierten Embeddings und hilft Teams so dabei, häufige Ticketarten zu identifizieren und das Ticketvolumen in den einzelnen Clustern zu verfolgen.
Jeder Cluster erhält eine KI-generierte Beschreibung und Lösung. Außerdem kann die Registerkarte „Zu diesem Cluster gehörende Tickets“ aktiviert werden, sodass Mitarbeiter weitere Tickets anzeigen können, die zum selben Cluster gehören wie das aktuell angezeigte Ticket.
Frühere Clustering-Läufe werden in der Datenbank archiviert, sodass Teams mithilfe des Cluster-Endpunkts der API Berichte darüber erstellen können, wie sich das Clustervolumen im Laufe der Zeit verändert.


Für MSPs, die ein hohes Ticketvolumen bewältigen, bietet dies den Teams eine weitere Möglichkeit, wiederkehrende Probleme zu erkennen, Trends zu identifizieren und zu verstehen, woher die Nachfrage stammt.
Das Gantt-Diagramm wurde aktualisiert und bietet nun eine verbesserte Darstellung in den Ansichten „Tickets“, „Agenten“ und „Projekte“.



Alle bisherigen Funktionen bleiben unverändert, allerdings kommen bei den Gantt-Diagrammen nun neue Komponenten zum Einsatz. Damit wird die Grundlage für weitere Verbesserungen in zukünftigen Versionen geschaffen, darunter die Darstellung von Abhängigkeiten, Filteroptionen für verschiedene Ansichten und vieles mehr.
Für Teams, die Projekte in HaloPSA verwalten, sollten diese visuellen Verbesserungen die Projektplanung und -terminierung vereinfachen.
Unter „Benutzerkonfiguration“ steht nun ein neues Modul „Sicherheitsfragen“ zur Verfügung.
Auf diese Weise können Teams Fragen zur Identitätsprüfung für Benutzer einrichten, die sich beim Service Desk melden. Die Fragen, die die Benutzer beantworten müssen, lassen sich konfigurieren, wobei optional eine Überprüfung der Mindest- und Höchstlänge sowie der Übereinstimmung mit regulären Ausdrücken möglich ist.
Die Teams können außerdem festlegen, wie viele Fragen gestellt werden – bis zu maximal fünf – sowie die Schwellenwerte für das Bestehen und das Nichtbestehen. Dazu gehört die Festlegung, wie viele Fragen richtig beantwortet werden müssen und wie viele falsche Antworten zulässig sind.

Benutzer, die ihre Antworten noch nicht festgelegt haben, werden auf dem Portal dazu aufgefordert. Sie können ihre Antworten außerdem jederzeit auf der Seite „Einstellungen“ aktualisieren.
Zusätzliche Sicherheitsvorkehrungen ermöglichen es den Teams zu entscheiden, ob 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 Validierung erfolgreich ist, wird der Benutzer für diesen Aufruf gespeichert.

Dies hilft den Teams dabei, bei der telefonischen Unterstützung der Nutzer einen strukturierteren Überprüfungsprozess einzuführen.
Für Tickets steht nun ein neuer benutzerdefinierter Feldtyp „Anhang“ zur Verfügung.
Diese Option kann bei der Konfiguration benutzerdefinierter Felder hinzugefügt werden und setzt voraus, dass clientseitige Uploads aktiviert sind.
Wird das Feld einem Ticket-Typ hinzugefügt, erscheint es beim Erstellen eines neuen Tickets im Portal als Dropzone. Es unterstützt das Hochladen mehrerer Dateien, wodurch es für Benutzer einfacher wird, im Rahmen des Ticket-Einreichungsprozesses Begleitdateien bereitzustellen.
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.
Von dort aus können sie genauso wie andere Anhänge verwaltet werden, einschließlich der endgültigen Löschung.

Geplante Berichte können nun an Verteilerlisten gesendet werden.
Bei der Konfiguration der Empfänger für einen geplanten Bericht steht eine neue Option „Empfängertyp“ zur Verfügung. Wenn Sie diese Option von „Manuell“ auf „Verteilerliste“ umstellen, können Benutzer eine vorhandene Verteilerliste als Empfänger auswählen.

Dadurch entfällt die Notwendigkeit, in jedem Bericht einzelne E-Mail-Adressen zu pflegen. Wenn sich die Zusammensetzung des Teams ändert, kann die Verteilerliste zentral aktualisiert werden, wodurch die Verwaltung der geplanten Berichte vereinfacht wird.
Benutzer können nun direkt aus den Anlagenstammsätzen im Self-Service-Portal Tickets erstellen.
Für ein Konfigurationselement oder einen Asset-Typ kann ein Standard-Ticket-Typ festgelegt werden. Auf diese Weise können Benutzer ein Problem oder eine Anfrage im Zusammenhang mit einem bestimmten Asset melden, ohne die Seite verlassen und die Asset-Details manuell erneut eingeben zu müssen.

Für Teams, die Kundenanlagen in HaloPSA verwalten, trägt dies dazu bei, doppelte Dateneingaben zu vermeiden und sicherzustellen, dass anlagenbezogene Anfragen von Anfang an dem richtigen Datensatz zugeordnet werden.
Die Ausgabenarten unterstützen nun neue Felder für „Art“ und „Satz“.
Auf diese Weise lässt sich eine Spesenart als Entfernungsspesenart mit einem festgelegten Kilometersatz konfigurieren. Wenn eine Entfernungsspesenart ausgewählt wird, werden die Kosten automatisch auf der Grundlage des Satzes und der zurückgelegten Entfernung berechnet.


HaloPSA bietet nun eine Integration mit dem Intermedia Contact Center.
Mit dieser Funktion kann eine Anfrage von Intermedia an HaloPSA gesendet werden, sobald ein Anruf in der Call-Center-Agenten-Anwendung von Intermedia eingeht.
Sobald ein Mitarbeiter einen Anruf entgegennimmt, stehen zwei konfigurierbare Optionen zur Verfügung. Der Anrufbildschirm kann automatisch in einem neuen Tab geöffnet werden, oder es erscheint eine Benachrichtigung, auf die der Mitarbeiter klicken kann, um den Anrufbildschirm zu öffnen.
HaloPSA versucht, den Nutzer anhand seiner Telefonnummer zu identifizieren. Wenn ein Ticket angelegt oder ein bestehendes Ticket mit Informationen aus dem Anruf aktualisiert wird, können die Teams entscheiden, ob die Anrufaufzeichnung als Anhang zum Ticket hinzugefügt werden soll. Durch Öffnen des Anhangs wird der Link zur Anrufaufzeichnung aufgerufen.
Dadurch profitieren Teams von einer engeren Verzahnung zwischen der Anrufbearbeitung und der Ticketverwaltung, was den Mitarbeitern hilft, die Anrufdaten dem richtigen Kundendatensatz zuzuordnen.
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.