Aktionen
Im Menü können Sie ticket- und artikelbasierte Aktionen konfigurieren. Aktionen sind individuell konfigurierte Funktionen (Macro Actions), die unter bestimmten Voraussetzungen zur Verfügung stehen. Sie ermöglichen die Bearbeitung von Tickets in Abhängigkeit vom aktuellen Ticketzustand und stellen damit die Funktionen für die prozessorientierte Verwendung von KIX bereit.
Mit dem Anlegen eigener Aktionen und der Festlegung, wem wann welche Aktion zur Verfügung steht, können Sie das System an den Workflow Ihres Unternehmens anpassen und den Agenten genau die Funktionen bereitstellen, die sie für die tägliche Serviceerbringung benötigen.
Aktionen werden stets auf bestehende Tickets und deren Artikel angewendet. Im Unterschied dazu werden Vorlagen nur auf neue Tickets angewendet.
Initiale Aktionen sind bspw. die Standardfunktionen wie das Schließen und Bearbeiten von Tickets oder das Beantworten und Weiterleiten von E-Mails.
KIX unterscheidet je nach referenziertem Bezugsobjekt zwischen Ticketaktionen und Artikelaktionen.
Ticketaktionen
Ticketaktionen sind Aktionen, die auf bestehende Tickets angewendet werden. Sie ermöglichen bspw. die Bearbeitung von Tickets in Abhängigkeit vom aktuellen Ticketstatus und stellen somit die Grundlage für eine prozessorientierte Verwendung von KIX bereit.
Die Bearbeitungsmöglichkeiten am Ticket können abhängig sein vom Inhalt, Bearbeitungszustand und dem aufrufenden Nutzer.
Ticketaktionen können je nach Konfiguration sowohl für das Agentenportal als auch für das Self Service Portal bereitgestellt werden. Sie stehen dann als Schaltflächen der Ticketdetailansicht zur Verfügung.
Abb.: Ticketaktionen an einem Ticket im Agentenportal
Abb.: Ticketaktionen an einem Ticket im Self Service Portal
Hinweis
Damit Ticketaktionen im Self Service Portal verfügbar sind, müssen sie dem Kontext "Kunde" und der Rolle "Customer" zugewiesen werden.
Ticketaktionen können dialogbasiert oder nicht-dialogbasiert sein:
Nicht-dialogbasierte Aktionen lösen beim Anklicken eine Hintergrundaktion aus.
Mit diesen sog. One-Click-Actions können bspw. Tickets mit vordefinierten Werten gefüllt und/oder sofort geschlossen werden.
Nicht-dialogbasierte Aktionen können bspw. sein:
Urlaubsantrag genehmigen
(Genehmigungsstatus setzen und Ticket schließen)
Zurück ins Team Servicedesk verschieben
(Team "Servicedesk" setzen)
Weiterleieiner Serviceanfrage inkl. Anhänge an den Hersteller mit gleichzeitigem Schließen des Tickets
Als Spam einordnen und ins Junk-Team verschieben
(Team "Junk" setzen)
Warte 2 Tage
(Warten-Status mit Angabe der Zeitdifferenz von 2 Tagen setzen)
Warte bis zum nächsten Arbeitstag
(Warten-Status setzen mit Angabe der Zeitdifferenz 1 Tag und Zielzeit "Beginn Servicezeit").
Dialogbasierte Aktionen öffnen ein zusätzliches Dialogfenster zur Eingabe von Ticketinformationen.
Beispielsweise, um in einem konkreten Störfall weitere Ticketinformationen zu hinterlegen oder zum Eintragen der Sollzeit.
Welche Formularfelder der Dialog enthält, können Sie individuell konfigurieren.
Artikelaktionen
Artikelaktionen werden immer auf einen bestehenden Artikel angewendet und stehen somit direkt am Artikel zur Verfügung.
Abb.: Artikelaktionen am Artikel
Initiale Artikelaktionen sind beispielsweise die Aktionen zum Beantworten und Weiterleiten von E-Mails oder zum Teilen des Artikels. Diese Aktionen sind bereits konfiguriert und können nach Bedarf angepasst werden. Beispielsweise, um der Antwortmail das betroffene Asset mitzugeben.
Sie können weitere Artikelaktionen nach Bedarf anlegen, um bspw. verschiedene Antwortmöglichkeiten für die Weiterleitung oder Beantwortung eines Artikels parat zu haben. Zudem können Sie festlegen, unter welchen Voraussetzungen eine Aktion welchen Nutzern zur Verfügung steht.
Anwendungsfälle für Artikelaktionen können sein:
Weiterleiten fehlgeleiteter E-Mails mit Rückmeldung an den Absender mit nur einem Klick
Weiterleiten von E-Mails an einen externen Dienstleister mit Auswahl der anzuhängenden Informationen bzw. Entfernen von betriebsinterner Informationen sowie gleichzeitigem Schließen des Tickets
Anlegen mehrerer, unterschiedlicher Weiterleitungs-Vorlagen für verschiedene Dienstleister oder Hersteller. Der Empfänger, betroffener Service/SLA sowie der Status des Tickets sind bereits vorausgewählt, der variable Wartezeitpunkt wird durch den Agenten gesetzt.
Hinweise:
Die Artikelaktionen zum Bearbeiten und Löschen eines Artikels sind initial vorhanden, jedoch deaktiviert (ungültig).
Sie können diese Aktionen bei Bedarf aktivieren und nachkonfigurieren, um bspw. Berechtigungen zu definieren.
Artikelaktionen, die am Ticket zulässig sind, werden an allen Artikeln angezeigt.
Artikelaktionen können aktuell nur für das Agentenportal bereitgestellt werden.
Navigieren Sie im Explorer zu .
Im Contentbereich wird eine Tabelle geöffnet, die alle im System angelegten Aktionen auflistet.
Klicken Sie in der Tabelle auf .
Es wird ein Formulardialog geöffnet, in dem Sie Aktion anlegen können.
Füllen Sie das Formular aus.
(siehe
Setzen Sie die Gültigkeit auf "gültig".
Speichern Sie Ihre Eingaben abschließend mit .
Die Aktion steht nun gemäß seiner Konfiguration in den Ticketdetails zur Verfügung.
Navigieren Sie im Explorer zu .
Im Contentbereich wird eine Tabelle geöffnet, die alle im System angelegten Aktionen auflistet.
Klicken Sie in der Tabelle auf die zu bearbeitende Aktion.
Es wird ein Formular-Dialog geöffnet, in welchem Sie schrittweise die Konfiguration der Aktion ändern können.
Ändern Sie die Angaben nach Erfordernis.
Übernehmen Sie Ihre Änderungen abschließend mit .
Die geänderte Aktion steht nun unter den definierten Voraussetzungen in den Ticketdetails zur Verfügung. Die Änderungen sind sofort wirksam.
Navigieren Sie im Explorer zu .
Im Contentbereich wird eine Tabelle geöffnet, die alle im System angelegten Aktionen auflistet.
Markieren Sie die zu duplizierende Aktion mit einem Häkchen (keine Mehrfachauswahl).
Klicken Sie in der Tabelle auf .
Die Schaltfläche ist nur aktiv, wenn genau 1 Dynamisches Feld ausgewählt ist.
Es wird ein eigenständiges Duplikat der gewählten Aktion angelegt und geöffnet.
Die Konfiguration des Duplikats entspricht seiner Quelle. Sie können die Konfiguration des Duplikats nach Bedarf ändern.
Der Name des Duplikats lautet standardmäßig Kopie von [Name der Aktion]. Sie können diesen Namen beibehalten oder das Duplikat anders benennen.
Ändern Sie die Angaben im Duplikat nach Erfordernis und übernehmen Sie die Änderungen mit .
Das Duplikat steht nun gemäß seiner Konfiguration in den Ticketdetails zur Verfügung.
Die Konfiguration einer Aktion erfolgt schrittweise.
Um zum jeweils nächsten Schritt zu gelangen oder um zwischen den einzelnen Schritten zu wechseln, klicken Sie bitte auf die kleinen blauen Pfeilschaltflächen oder auf die dazwischen befindlichen blauen Punkte.
Hinweis
Achten Sie bei der Konfiguration eigener Aktionen darauf, dass beim Erstellen neuer Tickets mindestens die erforderlichen Pflichtangaben am Ticket gesetzt werden.
In diesem Schritt hinterlegen Sie die Stammdaten und den Nutzungskontext der Aktion und legen fest, ob die Aktion am Ticket oder am Artikel verfügbar sein soll.
Abb.: Beispielkonfiguration Artikel-Informationen
Parameter | Beschreibung |
|---|---|
Nutzungskontext | Mit dem gewählten Nutzungskontext definieren Sie, in welchem Portal die Aktion zur Verfügung steht.
HinweisAb Version 29 kann als Nutzungskontext nur noch Kunde ODER Agent gewählt werden. Für bereits bestehende Aktionen heißt das: Wird eine Aktion bearbeitet, die einst für beide Nutzungskontexte angelegt wurde, wird nur der Nutzungskontext Agent übernommen. Soll eine Aktion in beiden Portalen verfügbar sein, so duplizieren Sie eine fertig konfigurierte Aktion und passen Sie im Duplikat den Nutzungskontext und die Rollen entsprechend an. |
Referenzobjekt | Wählen Sie aus, ob die Aktion auf ein Ticket oder auf einen Artikel angewendet werden soll.
|
Name | Interne Bezeichnung für die Aktion. Unter dieser Bezeichnung wird die Aktion im System geführt. |
Label | Beschriftung der Schaltfläche in der Programmoberfläche (Anzeigename). |
Icon | Wählen Sie optional ein Icon aus, mit dem die Aktion grafisch gekennzeichnet wird. Das Icon wird auf der Schaltfläche links neben dem Label angezeigt. |
Verhalten | Das gewählte Verhalten steuert, was beim Ausführen der Aktion passieren soll. Die Auswahlmöglichkeiten hängen vom gewählten Referenzobjekt ab.
|
Gruppe | Optional: Zuordnung der Aktion zu einer Aktionengruppe |
Rang | Optional: Legt die Reihenfolge der Aktionen-Schaltfläche in der Ticketdetailansicht fest. Eine Aktion mit einem niedrigeren Rang wird weiter links angeordnet. 0 ist ein gültiger Wert. Ist kein Wert angegeben, erhält der Rang den Wert NULL und die Aktion wird links angeordnet. Bei gleicher Prioritätsangabe werden die Aktionen in alphabetischer Reihenfolge angezeigt. Die Standardreihenfolge der Aktionen ist:
|
Nutzereingabe erforderlich | Wählen Sie aus, ob die Aktion eine Nutzereingabe erfordert.
|
Tags | Optional: Hinterlegen oder Auswählen von Schlagwörtern zur Kennzeichnung dieses Konfigurationsobjektes. Dient der Suche nach zusammengehörenden Konfigurationsobjekten sowie deren Konfigurationsexport. (s. auch: Tagging von Objekten). |
Kommentar | Optional: Hinterlegen Sie hier Notizen zur Aktion |
Gültigkeit |
|
Mit dem Setzen von Filtern definieren Sie, unter welchen Voraussetzungen eine Aktion zur Verfügung steht.
Beispiele können sein:
Die Ticketaktion "Urlaubsantrag genehmigen" steht nur den Verantwortlichen am Ticket zur Verfügung, wenn im Betreff eines Tickets "Urlaubsantrag" steht. In allen anderen Tickets ist diese Schaltfläche ausgeblendet.
Die Artikelaktion "Weiterleiten an Hersteller" steht am Artikel nur dann zur Verfügung, wenn der Bearbeiter einem bestimmten Team angehört und wenn es sich um eine Störung bei ausgewählten Assets handelt.
Die Ticketaktion steht nur dann zur Verfügung, wenn der angemeldete Nutzer die Rolle Ticket Agent besitzt und auch der Verantwortliche am Ticket ist.
Rollen
Wählen Sie aus, welchen Rollen Sie die Berechtigung zu dieser Aktion erteilen.
Wichtig: Beachten Sie die Berechtigungen innerhalb der Rollen!
Damit eine Aktion im Self Service Portal zur Verfügung steht, wird mindestens die Rolle "Customer" benötigt.
Verwenden Sie diese Auswahl ausschließlich für Rollen, um deren Berechtigungen hinsichtlich Aktionen zu erweitern. Anderenfalls findet eine Einschränkung der Berechtigungen statt (z. B. bei den Rollen "Super User" und "System Admin").
Wichtig
Für die gewählten Rollen wird explizit ein READ für Aktionen und Vorlagen gesetzt.
Vergeben Sie daher diese Berechtigung niemals auf Rollen, die mehr als Leserechte auf Aktionen und Vorlagen haben!
Beispiel: Sie konfigurieren eine Aktion zum Bearbeiten eines Ticket und wählen die Rolle "Ticket Reader" aus. Die Aktion wird nicht angezeigt, weil die Rolle "Ticket Reader" keine Berechtigung für die Ticketbearbeitung besitzt.
Filter
Durch Setzen von Filtern können Sie die Verfügbarkeit der Aktion optional weiter einschränken.
Sie legen damit fest, unter welchen Bedingungen eine Aktion zur Verfügung steht. Die Aktion steht an allen Tickets zur Verfügung, welche den hier angegebenen Parametern entsprechen.
Basis der Filter sind die gewählten Rollen.
Rollen: Schränkt die Verfügbarkeit der Aktion auf die hier angegebenen Rollen ein.
Filter: Legen Sie hier die Filterbedingungen fest.
Die Angabe der Filter erfolgt analog der Logik in der Komplexsuche:
1. Spalte: Angabe der Filterattribute
Definiert, welches Attribut geprüft werden soll.
2. Spalte: Suchoperatoren (enthalten in, beginnt mit, endet mit, ist gleich, etc.)
3. Spalte: Werte
Definiert, auf welche Werte das in Spalte 1 angegebene Attribut geprüft wird.
Sofern unter Aktionsinformationen das Referenz Objekt "Ticket" gewählt ist, stehen alle ticketbasierten Filter sowie Dynamischen Felder (außer Typ Checklist) zur Auswahl. Für Dynamische Felder des Typs Text und Textarea steht Ihnen außerdem die Wildcard-Suche zur Verfügung (Suche mit * als Platzhalter für unbekannte Textstellen).
Sie können "gültig" und "(temporär) ungültig" gesetzte Objekte und Attribute auswählen. Auf "ungültig" gesetzte Dynamische Felder finden jedoch bei Ausführung der Aktion keine Verwendung.
Die Verwendung von KIX Platzhaltern (z. B. <KIX_CURRENT_UserID>) ist möglich. Platzhalter müssen manuell ins Auswahlfeld eingetragen und mit ENTER bestätigt werden.
Sie können relative Zeitangaben definieren, z. B. erstellte Tickets innerhalb der letzten 24 Stunden.
Sie können die Filter kombinieren. Die einzelnen Filterblöcke sind ODER-verknüpft. Die Filter innerhalb eines Filterblocks sind UND-verknüpft.
Sie können somit bspw. festlegen, dass eine Aktion nur den Nutzern mit Rolle "Ticket Agent" zur Verfügung steht. Und auch nur dann, wenn das Ticket den Status "offen" UND den Typ "Störung" hat ODER wenn das Ticket den Typ "unklassifiziert" UND den Status "geschlossen" besitzt UND vom Team "Service Desk" ist.
Abb.: Verknüpfung von Filtern
Mit den Plus- und Minus-Schaltflächen können Sie weitere Filter hinzufügen (
) oder Filter entfernen (
)
Vorgelagerte Aktionen (Pre-Actions) sind konfigurierte Macros, die im Hintergrund ausgeführt werden, sobald die Aktion angeklickt wird.
Die Konfiguration der Pre Actions erfolgt analog der Konfiguration der Aktionen in Jobs (s. auch: Konfiguration eines Jobs)
Abb.: Konfigurationsbeispiel von Pre Actions
Überspringen Sie diesen Schritt, wenn Sie keine vorgelagerten Aktionen konfigurieren möchten.
Die Ausführung der Pre Actions ist abhängig davon, ob die Aktion dialogbasiert ist oder nicht.
In dialogbasierten Aktionen:
Die Pre Actions werden direkt nach dem Anklicken der Aktion und noch vor dem Öffnen des Dialogfensters ausgeführt.
Bricht ein Nutzer eine Aktion ab, erhält er einen Hinweis, dass im Hintergrund eine Aktion ausgeführt wird.
In nicht-dialogbasierten Aktionen (One-Click-Actions):
Legen Sie fest, was im Hintergrund passieren soll, sobald der Nutzer die Aktion anklickt. Bspw. das Ticket ins "Junk"-Team verschieben, einen Wartestatus oder den Verantwortlichen am Ticket setzen.
Sofern in den Aktionsinformationen festgelegt, erhält der Agent nach Ausführung der Aktion eine entsprechende Hinweismeldung.
In nicht-dialogbasierten Aktionen finden die Eingabefelder in Schritt 4 keine Berücksichtigung. Deren Steuerung erfolgt ausschließlich über die Pre- und/oder Post- Actions.
Hinweise:
Vorgelagerte Aktionen werden vom Self Service Portal nicht unterstützt.
Sie können daher nicht konfiguriert werden, wenn als Nutzungskontext "Kunde" gewählt wurde.
Vorgelagerte Aktionen werden mit der Nutzerkennung des aufrufenden Nutzers ausgeführt.
Das bedeutet, eine direkte Nutzung der Aktionen nur durch ein Backend-API-Aufruf ist nicht möglich.
Geben Sie bitte eine Differenz zur Wartezeit in Sekunden an, wenn Sie einen Warten-Status setzen (z. B. "Warten zur Erinnerung" oder "Warten auf erfolgreich schließen").
Damit wird das Datum automatisch gesetzt, sodass das Ticket auch ohne manuelle Zeitangabe geschlossen werden kann.
Tipp
Die Macro Action Loop|Schleife kann verwendet werden, um Macros an referenzierten Tickets auszuführen und beliebig zu verschachteln.
Hier legen Sie fest, welche Eingabe- bzw. Auswahlfelder im Formular enthalten sein sollen und gestalten das Layout des Formulars. Dazu steht Ihnen ein Formulardesigner zur Verfügung, der Ihnen die visuelle Gestaltung des Formulars ermöglicht.
Alternativ können Sie den JSON-Editor im Expertenmodus nutzen.
Warnung
Verwenden Sie den Expertenmodus nur, wenn Sie ausreichende Fachkenntnisse über die KIX-Struktur und über JSON besitzen. Insbesondere, wenn Sie Änderungen an den Standardformularen vornehmen. Im Fehlerfall könnten die Formulare nicht mehr bedienbar sein.
Klicken Sie auf , um die Eingabefelder und deren Anordnung im Formular zu konfigurieren. Der Formulardesigner wird geöffnet. Richten Sie hier eine oder mehrere Formularseiten ein und ordnen Sie auf diesen die Eingabe- und Auswahlfelder in Formulargruppen an. Das Layout der Seiten basiert auf einem zwölfspaltiges Grid (analog Bootstrap), sodass Sie die Formularfelder und Gruppen auch nebeneinander anordnen und das responsive Verhalten steuern können.
Ausführliche Informationen zum Formulardesigner finden Sie hier:
Alternativ: Klicken Sie auf , um den JSON-Editor zu öffnen. Dieser bildet die vollständige und jeweils aktuelle Konfiguration des Formulars als JSON-Struktur ab. Änderungen, die im Formulardesigner vorgenommen wurden, werden sofort in die JSON-Struktur übertragen.
Weiterführende Informationen zum Expertenmodus: Expertenmodus
Klicken Sie nach dem Erstellen oder Ändern des Formulars auf , um es bereitzustellen.
Post Actions sind nachgelagerte Aktionen, die direkt im Anschluss ausgeführt werden sollen. Beispielsweise das Ticket schließen, nachdem der Urlaubsantrag abgelehnt wurde. Die Konfiguration erfolgt analog der Pre Actions
Überspringen Sie diesen Schritt, wenn Sie keine nachgelagerten Aktionen definieren wollen.
Nachgelagerte Aktionen werden im Hintergrund ausgeführt, unmittelbar nach dem der Nutzer in dialogbasierten Aktionen auf die Schaltfläche geklickt hat. In nicht-dialogbasierten Aktionen werden nachgelagerte Aktionen ausgeführt, sobald die Aktion angeklickt wird.
Hinweise:
Nachgelagerte Aktionen werden vom Self Service Portal nicht unterstützt.
Sie können daher nicht konfiguriert werden, wenn als Nutzungskontext "Kunde" gewählt wurde.
Nachgelagerte Aktionen werden mit der Nutzerkennung des aufrufenden Nutzers ausgeführt.
Das bedeutet, eine direkte Nutzung der Aktionen nur durch ein Backend-API-Aufruf ist nicht möglich.
Geben Sie bitte eine Differenz zur Wartezeit in Sekunden an, wenn Sie einen Warten-Status setzen (z. B. "Warten zur Erinnerung" oder "Warten auf erfolgreich schließen").
Damit wird das Datum automatisch gesetzt, sodass das Ticket auch ohne manuelle Zeitangabe geschlossen werden kann.
Navigieren Sie im Explorer zu .
Im Contentbereich wird eine Tabelle geöffnet, die alle im System angelegten Aktionen auflistet.
Wählen Sie in der Tabelle die zu löschende Aktion mit einem Häkchen aus (Mehrfachauswahl möglich).
Klicken Sie im Tabellenkopf auf .
Das Löschen kann nicht rückgängig gemacht werden. Daher wird eine Sicherheitsabfrage angezeigt.
Beantworten Sie die Sicherheitsabfrage mit , um den Löschvorgang zu bestätigen.
Es werden rekursiv alle Macros und Sub-Macros (Pre- und Post-Actions) gelöscht. Sofern jedoch noch interne Referenzen bestehen, kann die Aktion nicht gelöscht werden. Sie erhalten dann einen entsprechenden Hinweis.
Alternativ zum Löschen können Sie eine Aktion auf "ungültig" oder "temporär ungültig" setzen. Die Aktion steht dann in den Ticketoberflächen nicht zur Verfügung. Eine ungültige Aktion kann jederzeit wieder auf "gültig" gesetzt werden.
Tipp
Mit dem Konsolen-Kommando Console::Command::Maint::Automation::DeleteNotReferencedMacros können Sie nicht verwendete Macros löschen (Menü ).