Lernen Sie anhand von Beispielen

Auf dieser Seite werden einige Beispiele für Core Workflows vorgestellt. Um mehr über Core Workflows im Detail zu erfahren, schauen Sie sich zuerst Wie funktionieren sie? an.

Grundlagen

Alle unten aufgeführten Core Workflow-Beispiele sind im gleichen System konfiguriert. Im Vergleich zu einer Neuinstallation von Zammad verfügt das System über einige zusätzliche Gruppen und einige benutzerdefinierte Objektattribute, die Sie in den jeweiligen Beispielen finden. Betrachten Sie diese Beispiele als Inspiration und passen Sie die Arbeitsabläufe an Ihre Prozesse an.

Gruppenabhängige Felder

Oft haben verschiedene Teams (wie Vertrieb, Support oder 2nd Level) leicht unterschiedliche Prozesse, um Tickets effektiv zu bearbeiten. Mit gruppenbasierten Workflows können Sie das Handling eines Tickets anpassen, indem Sie die angezeigten Felder, die erforderlichen Eingaben und die verfügbaren Optionen auf der Grundlage der zugewiesenen Gruppe definieren.

Problem/Szenario

Wenn ein Ticket in der Gruppe 2nd Level erstellt oder in diese verschoben wird, muss das Kategoriefeld eingeschränkt werden, einige Felder müssen angezeigt werden und bestimmte Felder sind Pflichtfelder, damit alle relevanten Informationen für den 2nd Level Support im Ticket vorhanden sind.

Workflow-Konfiguration

Bereich	Konfiguration	Notiz
Objekt	Ticket
Kontext	Erstellmaske Bearbeitungsmaske
Ausgewählte Bedingungen	Gruppe ist 2nd Level
Gespeicherte Bedingungen		Nicht verwendet, da es um ungespeicherte Änderungen in der UI geht sofort, wenn die Gruppe auf 2nd Level gesetzt wird.
Aktion	Category anzeigen Category fest eingestellt auf 2nd Level (und alle Unterkategorien) Operating System und Software used anzeigen Operating System und Software used als erforderlich festlegen

Konfiguration in der UI

Freigabeprozess

In vielen Organisationen ist eine Freigabe erforderlich, um nachfolgende Prozesse in Gang zu setzen. Diese Freigabe ist in der Regel auf eine bestimmte Gruppe von Personen beschränkt, um sicherzustellen, dass alle Anforderungen für den nachfolgenden Prozess erfüllt sind.

Problem/Szenario

Die Freigabe eines Kundenanliegens kann nur von Benutzern mit der Rolle Approval Person durchgeführt werden. Solange diese Freigabe nicht erfolgt ist, muss der Wert fest auf Nein gesetzt werden, es sei denn, die genehmigende Person sieht das Ticket an.

Auf der Grundlage des Freigabestatus können zusätzliche Automatisierungsprozesse eingerichtet werden (z.B. ein Trigger zur Erhöhung der Priorität oder zur Zuweisung eines bestimmten Agenten).

Workflow-Konfiguration

Bereich	Konfiguration	Notiz
Objekt	Ticket
Kontext	Erstellmaske Bearbeitungsmaske
Ausgewählte Bedingungen	Rolle ist nicht Approval Person	Prüft, ob die Rolle nicht Approval Person für ungespeicherte Änderungen im Ticket ist.
Gespeicherte Bedingungen	Approved ist nicht yes	Prüft, ob die Freigabe noch nicht auf yes gesetzt ist.
Aktion	Approved fest eingestellt auf no	Verhindert Änderungen, wenn die oben genannten Bedingungen erfüllt sind.

Konfiguration in der UI

Erzwingen der Ticket-Kategorisierung

Um aussagekräftige Zahlen für Ihre Statistik zu erhalten, kann es Sinn machen, bestimmte Attribute zu erzwingen, die vor dem Schließen des Tickets ausgefüllt werden müssen.

Problem/Szenario

Das Feld Category muss zum Pflichtfeld werden, wenn ein Agent den Status geschlossen oder auf Schließen warten setzen will, um eine Kategorisierung zu erzwingen.

Workflow-Konfiguration

Bereich	Konfiguration	Notiz
Objekt	Ticket
Kontext	Erstellmaske Bearbeitungsmaske
Ausgewählte Bedingungen	Status ist geschlossen oder warten auf Schließen	Ausgewählte Bedingung, weil sie vor dem Speichern geprüft werden muss.
Aktion	Category als erforderlich festlegen

Konfiguration in der UI

Ticket-Übergabe-Prozess

Eine Übergabe von einem Agenten an einen anderen kann mehr erfordern als nur einen Wechsel des Besitzers. Je nach Thema oder Prozess kann es sehr hilfreich sein, wenn der ursprüngliche Agent eine kleine Notiz hinterlässt, damit der neue Agent sofort weiß, was der Grund für die Übergabe ist und wo das Problem liegt.

Problem/Szenario

Agenten müssen einen kleinen Kommentar schreiben, wenn sie den Besitzer des Tickets ändern wollen. Es gibt ein benutzerdefiniertes Ticket-Attribut namens Handover, in das ein Text eingefügt werden kann. Dieses Feld ist standardmäßig ausgeblendet (Workflow 1) und wird nur angezeigt, wenn sich der Besitzer ändert. Außerdem muss es in einem solchen Fall auf obligatorisch gesetzt werden (Workflow 2).

Da das Feld nach dem Speichern der Änderung des Besitzers des Tickets ausgeblendet wird, muss der Text des Feldes durch einen Trigger als Artikel in das Ticket geschrieben werden. Andernfalls würde der neue Agent es gar nicht sehen.

Workflow-Konfiguration

Workflow 1Workflow 2Trigger

Dieser Workflow blendet das Feld grundsätzlich aus. Bitte beachten Sie die niedrigere Priorität, weshalb Zammad diesen Workflow zuerst ausführt.

Bereich	Konfiguration	Notiz
Objekt	Ticket
Kontext	Erstellmaske Bearbeitungsmaske
Ausgewählte Bedingungen		Keine Bedingung erforderlich, denn es sollte immer ausgeblendet sein.
Gespeicherte Bedingungen		Keine Bedingung erforderlich, denn es sollte immer ausgeblendet sein.
Aktion	Handover verstecken

Konfiguration in der UI

Workflow 1Workflow 2Trigger

Als Ergebnis enthält das Ticket einen Artikel vom Typ Notiz, der den vordefinierten Text und den Inhalt des Handover-Felds enthält.