Dynamisches Feldverhalten in das JSM-Kundenportal bringen

‍

‍

Warum die Genauigkeit der Portaldaten wichtig ist

Die meisten JSM-Tickets beginnen mit einem Formular. Was auch immer der Kunde ausfüllt, damit arbeitet das Support-Team von dort aus — Warteschlangen, SLAs, Automatisierungen, Berichte. Die Struktur dieser Daten entscheidet darüber, ob ein Ticket an der richtigen Stelle landet; die Genauigkeit entscheidet darüber, ob der Agent nachhaken muss, um die Lücken zu schließen.

Der Haken: Die Portaldaten sind nicht flach. Manche Felder sind erst sinnvoll, wenn ein anderes Feld einen bestimmten Wert hat. Einige Optionen sollten auf der Grundlage der zuvor ausgewählten Optionen eingegrenzt werden. Einige Felder sind in einem Szenario entscheidend, im nächsten irrelevant.

Atlassian deckt Teile davon bereits ab Werk ab. JSM-Formulare bieten bedingte Logik auf Abschnittsebene und ein ausgefeiltes Kundenerlebnis. Native Feldkonfiguration lässt Administratoren entscheiden, wie die Felder pro Anforderungstyp angezeigt werden (Name, Beschreibung, Erforderlich, Vorbefüllung). Was auf dem Portal schwieriger zu erreichen war, ist live, Reaktivität auf Feldebene — ein-/ausblenden, erforderlich/optional, Optionsfilterung, Wertezusammensetzung — abhängig von dem, was der Kunde gerade getan hat.

Das ist die Lücke, die die UI Modifications API von Atlassian öffnet — derzeit in Vorschau für Jira Service Management. Direkte, programmatische Kontrolle über benutzerdefinierte Felder und Systemfelder direkt im Portal.

Was ist jetzt möglich

Es gibt verschiedene Möglichkeiten, mit der UI Modifications API von Atlassian zu arbeiten — Atlassian-Apps von Drittanbietern mit skriptbasierten Ansätzen und ohne Code-Konfiguration sind verfügbar. In diesem Artikel wird ein praktisches Beispiel zur Verwendung von VIP.LEAN Behaviours Builder vorgestellt.

Ab heute VIP.LEAN Behaviours Builder unterstützt die Bildschirm zum Erstellen des JSM-Kundenportals für alle Feldtypen und Änderungsmethoden, die Atlassian derzeit über die UI Modifications API für das Portal verfügbar macht. Der Bildschirm zum Erstellen des Portals ist immer noch schmaler als die standardmäßigen Jira-Bildschirme zum Erstellen, Anzeigen und Übergehen. Hier ist die aktuelle Berichterstattung:

Die API-Oberfläche für Benutzeroberflächenänderungen von Atlassian für das JSM-Kundenportal — der Erstellungsbildschirm — die Ebene, auf der Behaviours Builder arbeitet. Quelle: Atlassian-Dokumentation für Entwickler.

Beispielszenario — eine Smart IT-Supportanfrage

Was wir erreichen wollten

Für dieses Szenario war das Ziel ein Portal-Erlebnis, das von Anfang bis Ende strikt gesteuert wird:

• Felder erscheinen nacheinander, in einer Kaskade — der Kunde wird nie mit allem auf einmal überfordert
• Nur die richtigen Felder werden angezeigt, basierend auf dem, was zuvor ausgewählt wurde
• Die Priorität wird nicht vom Kunden ausgewählt — sie wird automatisch aus der Kombination der vorherigen Felder berechnet
• Die Beschreibung ist kein Freitext-Dump — sie ist eine automatisch generierte Rich-Text-Zusammenfassung, die alle strukturierten Werte zusammenfasst, mit einem kleinen Freitextabschnitt, den der Kunde verwenden kann, um weitere wichtige Informationen hinzuzufügen

Das Design — vor jeder Konfiguration

Bevor Sie ein einzelnes Verhalten konfigurieren, sollten Sie den Kontrollfluss skizzieren, den Sie erreichen möchten. Die Funktionen, die Atlassian über die UI Modifications API zur Verfügung stellt, und das, was Behaviours Builder darüber hinaus zur Verfügung stellt, definieren, was möglich ist — und ein klares Design von Anfang an sorgt dafür, dass die Implementierung im Mittelpunkt steht.

Hier ist die Entscheidungsmatrix für dieses Beispiel:

Die vier Phasen der Kundenreise: Die Kategorie der Anfrage bestimmt das Unterauswahlfeld, die Unterauswahl in Kombination mit der Dringlichkeit bestimmt die Priorität und alle ausgewählten Werte fließen in die automatisch generierte Beschreibung ein.

Dieser Schritt erwies sich als der wichtigste Teil des Setups. Sobald die Entscheidungsmatrix klar war, wurde die eigentliche Konfiguration ziemlich einfach.

Das Ergebnis — Behaviours Builder in Aktion

Nach der Anwendung der Verhaltensmuster sieht das Portal wie folgt aus und verhält sich wie folgt:

Felder werden überlappt, wenn der Kunde eine Auswahl trifft. Die Priorität wird automatisch festgelegt. Die Beschreibung wird in Echtzeit als strukturierte Zusammenfassung erstellt. Schreibgeschützte Felder sind vor Änderungen geschützt.

So ist es aufgebaut — kein Scripting erforderlich

Die obige Konfiguration erfordert kein benutzerdefiniertes Scripting. Sobald die Logik festgelegt ist, kann ein Jira-Administrator sie direkt im Behaviours Builder konfigurieren.

Einige Funktionen, die dieses Szenario ermöglicht haben:

1. Steuerung auf Feldebene auf der gesamten unterstützten API-Oberfläche. Einblenden, Ausblenden, Erforderlich, Optional, Schreibgeschützt, Wert setzen, Filteroptionen, Bezeichnung, Beschreibung — alles verfügbar, wo es die Portal-API zulässt.
2. Bedingungen, die echte Entscheidungslogik modellieren können. Feldwerte werden mit grundlegenden Operatoren (UND, ODER, NICHT) zu Ausdrücken beliebiger Tiefe kombiniert. Die Prioritätsregel in diesem Beispiel hängt von mehreren Eingaben ab, daher wäre eine einfache Ein-Feld-Bedingung nicht ausreichend gewesen — Wenn es sich bei der betroffenen Hardware um einen Laptop oder ein Telefon handelt und die Dringlichkeit „Normal“ oder „Hoch“ ist, ist die Priorität „Hoch“.
3. Eine strukturierte Beschreibung anstelle eines leeren Textfeldes. Anstatt den Kunden zu bitten, alles manuell zu erklären, wird die Beschreibung aus den bereits bereitgestellten Antworten zusammengestellt — mit Überschriften, Tabellen und Formatierungen, die live erstellt werden, während das Formular ausgefüllt wird.
4. Wiederverwendbare Bedingungen, beide Zweige unter Kontrolle. Eine Bedingung wird einmal definiert und verwendet, um sowohl das wahre als auch das falsche Szenario zu steuern. Wenn der Anforderungskategorie ist Hardware lässt die Hardwarefelder erscheinen; derselbe Zustand verbirgt sie wieder, sobald der Kunde zur Software wechselt — gleiche Logik, gegenteiliges Ergebnis, keine doppelte Konfiguration.

In unserem Setup dauerte die Konfiguration etwa 15 Minuten, sobald die Entscheidungsmatrix klar war.

Ein Blick in den Behaviours Builder

Um die Konfiguration greifbar zu machen, hier drei Ansichten aus dem tatsächlichen Setup:

Die vollständige Liste der für dieses Portal konfigurierten Aktionen. Jede Aktion zielt auf ein Feld ab und wendet eine Änderung an: Einblenden, Ausblenden, Wert festlegen, Erforderlich festlegen, Filteroptionen. Zusammen orchestrieren sie die Kaskade.

Der Bedingungsausdruck, der die Priorität auf Hoch setzt — ein zusammengesetzter logischer Ausdruck, der die betroffene Hardware, den Softwarenamen und die Dringlichkeit kombiniert und visuell mit wiederverwendbaren Bausteinen konfiguriert ist.

Der Rich-Text-Editor, der die Beschreibung erstellt, ist live dabei, wie der Kunde das Formular ausfüllt. Feldwerte aus dem gesamten Formular werden in eine strukturierte Zusammenfassung mit Überschriften, einer Klassifizierungstabelle und den eigenen Eingaben des Kunden übernommen.

Was ist noch nicht abgedeckt

Ein paar ehrliche Hinweise dazu, was die Portalebene noch nicht kann:

• Der Anzeigebildschirm auf dem Portal wird nicht unterstützt. Die API für Benutzeroberflächenänderungen deckt heute den Bildschirm zum Erstellen des Portals ab. Die Ansichtsseite ist noch nicht Teil dieser Oberfläche — siehe die von Atlassian Dokumentation für Entwickler für den aktuellen Zustand.
• Interne Agentenansicht und Übergangsbildschirme für verwandte JSM-Workitems werden noch nicht unterstützt.
• Einige Feldtypen fehlen noch. Die API befindet sich in der Vorschauversion, und die unterstützten Feldtypen sind in der oben verlinkten Dokumentation aufgeführt. Optionsfelder sind beispielsweise noch nicht Teil des unterstützten Sets.

Probiere es selbst aus:

• Interaktive Komplettlösung: Schneller Rundgang
• Auf Jira Cloud installieren: Atlassian Marketplace

Wenn Sie ähnliche Portalszenarien gelöst haben — oder wenn es eines gibt, das wir als Nächstes behandeln sollen — würden wir uns freuen, davon zu hören.

‍