Lernen Sie anhand von Beispielen

Diese Seite enthält einige grundlegende Beispiele für Core Workflows. Natürlich können Sie bei Bedarf auch komplexere Workflows erstellen.

Um mehr über Core Workflows im Detail zu erfahren, gehen Sie zuerst zu Wie funktionieren sie?.

Gruppenbasierte Beispiele

Alle folgenden Workflows haben die gleichen Basiskonfigurationen. Der Workflow muss nicht alle Konfigurationen verwenden.

  • Gruppen:

    • Sales

    • Support

    • 2nd Level

  • Attribute:

    • Kategorie (Einfach-Baumauswahl-Feld, kein Pflichtfeld, nur Agenten)

    • Genehmigt (Boolean-Feld, kein Pflichtfeld, versteckt, false als Standard)

    • Betriebssystem (Textfeld, kein Pflichtfeld, versteckt)

    • Verwendete Software (Einfachauswahl-Feld, kein Pflichtfeld, versteckt)

  1. Gruppenspezifische Werte und Felder

    Dieser Workflow hängt vom Kategorie-Feld ab. Es verringert die möglichen auswählbaren Werte auf der Grundlage der ausgewählten Gruppe.

    Dies reduziert die Kategorieoptionen auf 2nd Level/*, Internal/* und Others. Außerdem werden weitere erforderliche Felder als Pflichtfelder und sichtbar gesetzt.

    Beispiel-Workflow, der bestimmte Werte und Felder für 2nd Level zeigt
    Das Ergebnis

    Dies zeigt die Agenten-Sicht bei Anwendung der oben genannten Workflows.

    Workflow zeigt Objektattribute an und schränkt die Optionen basierend auf der Auswahl in der Gruppe ein
  2. Genehmigungsprozess

    In diesem Fall ist approved standardmäßig für Agenten sichtbar. Für diesen Workflow wird eine zusätzliche Rolle Approval person benötigt (keine weiteren Berechtigungen).

    Beispiel-Workflow, der den Genehmigungs-Status auf bestimmte Rollen einschränkt

    Tipp

    Dieser Workflow funktioniert am besten in Kombination mit einem Trigger, aber technisch ist das nicht unbedingt erforderlich.

    Auswahlfelder können besser geeignet sein, da sie mehr Werte zulassen als nur ein einfaches true oder false.

    Das Ergebnis
    Der Workflow legt die möglichen Werte von "Approved ?" auf eine bestimmte Auswahl fest, die von der Rolle des Benutzers abhängt
  3. Vom Status abhängige Pflichtfelder

    Dieser Workflow legt Category als Pflichtfeld fest, wenn der Agent die Tickets auf geschlossen oder Warten auf Schließen setzen will, um die Kategorisierung zu erzwingen.

    Beispiel-Workflow, der Felder abhängig vom Ticketstatus als Pflichtfeld definiert
    Das Ergebnis
    Der Workflow definiert das Kategorie-Feld als Pflichtfeld, wenn als Status "geschlossen" oder "warten auf Schließen" gewählt wird

Prozess manuelle Ticketübergabe

In diesem Beispiel geht es um die Übergabe eines Tickets von einem Agenten an einen anderen:

  • Wenn der Besitzer des Tickets geändert wird, wird ein neues Textfeld („Handover“) für einen Kommentar eingeblendet

  • Dies darf nur sichtbar sein, wenn der Besitzer gewechselt wird, daher muss es grundsätzlich ausgeblendet werden

  • Die Eingabe in dieses Handover-Textfeld ist verpflichtend

  • Nach dem Speichern muss der Wert des Handover-Felds als Notiz zum Ticket hinzugefügt werden (mittels Trigger)

Ausblenden des Handover-Feldes
Ausblenden des Handover-Felds in Core Workflows
Handover-Feld einblenden und als Pflichtfeld setzen
Das Handover-Feld anzeigen und als Pflichtfeld festlegen
Trigger für die Erstellung eines neuen Artikels auf Basis des Handover-Inhalts
Handover-Inhalt in einen neuen Artikel schreiben

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