Skip to main content

Initial ausgelieferte Jobs

Mit KIX werden initial eine Reihe vorkonfigurierter Jobs ausgeliefert, die vom System genutzt werden.

Sofern unbedingt erforderlich, können Sie die Konfiguration der Jobs ändern. Achten Sie jedoch darauf, die Funktionsträchtigkeit des Systems nicht zu gefährden!

Anonymisierung

Mit diesem Job können Sie Tickets ab einem vordefinierten Zeitraum anonymisieren lassen, bspw. um sie datenschutzkonform zu archivieren. Sie können festlegen, zu welchem Zeitpunkt oder Event die Ausführung der Anonymisierung erfolgen soll und welche Daten dabei anonymisiert werden.

Dieser Job ist bereits für Sie vorbereitet, aber auf "ungültig" gesetzt. Möchten Sie den Job nutzen, setzen Sie ihn auf "gültig" und passen Sie die Konfiguration ggf. weiter an.

Folgende Ticketdaten können anonymisiert werden:

  • Bearbeiter

  • Verantwortlicher

  • Kontakt

  • Organisation

  • Historien-Einträge

  • Erstell- und Änderungsdatum für Tickets

  • Erstell- und Änderungsdatum für Artikel

  • an Artikeln hinterlegte E-Mail-Adressen.

Der Job nutzt das initial ausgelieferte Dynamische Feld "Anonymise Ticket", um darin den Anonymisierungsstatus am Ticket zu hinterlegen. Der Job ist initial so konfiguriert, dass alle Tickets bearbeitet werden, an welchem dieses Feld den Wert "ToDo" hat. Im Auslieferungszustand können Sie den Wert des Feldes nicht manuell setzen, da dieses in keinem Ticketdialog konfiguriert ist. Dies ist eine Sicherheitsmaßnahme, um ungewolltem Datenverlust vorzubeugen. Sie können einen neuen Job konfigurieren, der das Feld "Anonymise Ticket" mit den von Ihnen festgelegten Kriterien befüllt.

Den Job "Anonymisation" anpassen

  • Job Informationen

    Initial ist der Job auf "ungültig" gesetzt. Ausgeführt werden nur gültige Jobs. Setzen Sie daher den Job auf "gültig".

  • Ausführungsplan

    Legen Sie fest, zu welchem Zeitpunkt oder Ereignis die Anonymisierung erfolgen soll.

    Sie können die Konfiguration ändern oder ergänzen, indem Sie einen anderen Zeitpunkt für die Ausführung des Jobs festlegen oder ein anderes Event wählen, welches den Job auslöst.

    Initial wird der Job ausgelöst, sobald Änderungen am Dynamischen Feld "Anonymised Ticket" vorgenommen werden (Event: TicketDynamicFieldUpdate_AnonymiseTicket)

  • Filter

    Legen Sie fest, welche Tickets anonymisiert werden sollen. Sie können Filterkriterien hinzufügen oder ändern, um die Auswahl an Tickets einzuschränken.

    Initiale Konfiguration: Der Job wird ausgelöst, wenn das Dynamische Feld "Anonymise Ticket" den Wert "ToDo" hat.

  • Aktionen

    Legen Sie fest, welche Ticketdaten mit welchen Inhalte überschrieben werden sollen.

    Sie können die Konfiguration individuell anpassen und weitere Aktionen hinzufügen, indem Sie bspw. alle anonymisierten Tickets ins Team "Archiv" verschieben.

    Initiale Konfiguration:

    1. Bearbeiter setzen: 1 (admin)

    2. Verantwortlichen setzen: 1 (admin)

    3. Kontakt setzen: 1 (admin@localhost)

    4. Kunde setzen: 1 (MY_ORGA)

    5. Historie löschen:

      (OwnerUpdate|ResponsibleUpdate|CustomerUpdate|TicketLinkAdd|TicketLinkDelete|SendAnswer|SendAgentNotification|SendCustomerNotification|EmailAgent|EmailCustomer|FollowUp|Forward|LoopProtection|Subscribe|Unsubscribe)

      Ersetze : OwnerUpdate, ResponsibleUpdate, CustomerUpdate, TicketLinkAdd, TicketLinkDelete, SendAnswer, SendAgentNotification, SendCustomerNotification, EmailAgent, EmailCustomer, FollowUp, Forward, LoopProtection, Subscribe und Unsubscribe

      durch: Comment replaced by "Anonymisation".

    6. Erstellt von und Geändert von setzen: 1 (admin)

    7. Erstellt von und Geändert von für Artikel setzen:1 (admin)

    8. Artikel E-Mail Attribute setzen: jeweils "admin@localhost" für Bcc, Cc, Von und An.

    9. Dynamisches Feld setzen: AnonymiseTicket: 2

      Damit wird das dynamische Feld Anonymised Ticket auf den Wert "Done" gesetzt und somit das Ticket als ist anonymisiert gekennzeichnet. Das wird in der Oberfläche des Agentenportals angezeigt, sodass Sie auch nach allen anonymisierten Tickets suchen können.

Auto Set Planned Effort (Incident)

Setzt einen Standardwert als Vorgabe für die geplante Erfüllungszeit (Sollzeit).

Es wird die im Job definierte Sollzeit automatisch in das Dynamische Feld "PlannedEffort" gesetzt.

Gilt für Tickets des Typs "Vorfall".

Default: 30 Minuten

Sie können die Konfiguration des Jobs ändern, indem Sie bspw.:

  • den Wert der Sollzeit ändern

  • weitere den Job auslösende Events festlegen

  • über Filter definieren, unter welchen Voraussetzungen der Job die Sollzeit setzen soll

  • u.a.m.

Auto Set Planned Effort (Service Request)

Setzt einen Standardwert als Vorgabe für die geplante Erfüllungszeit (Sollzeit).

Es wird die im Job definierte Sollzeit automatisch in das Dynamische Feld "PlannedEffort" gesetzt.

Gilt für Tickets des Typs "Service Anfrage".

Default: 60 Minuten

Sie können die Konfiguration des Jobs ändern, indem Sie bspw.:

  • den Wert der Sollzeit ändern

  • weitere den Job auslösende Events festlegen

  • über Filter definieren, unter welchen Voraussetzungen der Job die Sollzeit setzen soll

  • u.a.m.

Create FAQ Suggestion

Der Job erstellt aus einem Artikel heraus einen neuen FAQ Eintrag, sofern am Artikel das Dynamische Feld "CreateFAQSuggestion" auf "ja" gesetzt ist (1. Aktion). 

Mit der 2. Aktion wird der Wert des Dynamischen Feld "CreateFAQSuggestion" für eine erneute Verwendung zurückgesetzt (Leerwert). 

Hinweis

Das Feld "CreateFAQSuggestion" steht nur in den Dialogen "Ticket bearbeiten" und "Ticket schließen" zur Verfügung, wenn als Kanal "Notiz" oder "E-Mail" gewählt ist.

Sie können bei Bedarf die Vorgabekonfigurationen in der 1. Aktion ändern, um andere Werte  in den FAQ Eintrag zusetzen oder den FAQ Eintrag einer anderen Kategorie zuzuordnen.

Initial sind im Job u. a. folgende Parameter vorgegeben:

  • Titel: Betreff des ersten Artikels

  • Kategorie: Misc

  • Ursache: Inhalt des ersten Artikels am Ticket

  • Lösung: Inhalt des Artikels welcher den Job auslöst.

  • Dynamische Felder: Verwandte Tickets → ID des Tickets (stellt die Verknüpfung zwischen Ticket und FAQ her)

Customer Response - reopen from pending

Der Job ändert bei einer Kundenrückmeldung via Self Service Portal den Status eines Tickets von "warten" in "offen".

Häufig werden Tickets auf einen Warten-Status gesetzt, wenn eine Rückmeldung des Kunden erwartet wird. Antwortet der Kunde zu einem späteren Zeitpunkt via Self Service Portal, setzt der Job den Status des Tickets auf "offen" und hebt damit die Relevanz des Tickets an. So wird das Ticket nicht vergessen und kann weiter bearbeitet oder abgeschlossen werden.

Initial müssen vom Erstellen des Tickets bis zur Antwort mindestens 5 Minuten vergehen, bevor der Status geändert wird. Sie können diese Zeitspanne bei Bedarf ändern. Wird der Filter-Parameter "Erstellt am" entfernt, wird das Ticket mit jeder Antwort auf "offen" gesetzt.

KIX Field Agent - Mobile Processing Rejected

Dieser Job wird für die Field Agent App benötigt. Er ermöglicht Nutzern, ein abgelehntes Ticket an das Team zurückzugeben, sodass es nicht mehr in den Aufgaben des Nutzers erscheint.

Setzt im Ticket den Bearbeiter und den Sperrstatus im Ticket, wenn in der Field Agend App das Ticket zurückgewiesen wird.

Ein eventuell gesperrtes Ticket könnte das Setzen des Bearbeiters verhindern. Um dies zu vermeiden, sind die Aktionen initial in folgender Reihenfolge konfiguriert:

  1. Sperrstatus setzen: unlock

  2. Bearbeiter setzen: 1 (admin)

Sie können bei Bedarf den zu setzenden Bearbeiter festlegen und weitere Macro-Aktionen hinzufügen.

Owner Out of Office - unlock ticket

Periodische Prüfung, welche Tickets entsperrt und als Bearbeiter den Systemnutzer setzt, wenn diese Tickets:

  • auf abwesende Besitzer gesperrt sind UND den Status mit Statustyp "neu" oder "offen" haben

    ODER:

  • Im Status "Warten zur Erinnerung" mit überschrittenem Wartezeitpunkt stehen.

Die Überprüfung findet täglich um 6:00, 12:00, 18:00 und 0:00 Uhr statt.

Falls erforderlich, können Sie den Job anpassen. Zum Beispiel, um das Prüfintervall oder den Bearbeiter zu ändern.

Der Abwesenheitszeitraum kann festgelegt werden:

  • in der Konfiguration eines Nutzers

    (der Nutzer muss einem Nutzungskontext zugewiesen sein)

  • in den Persönlichen Einstellungen eines Nutzers.

Password Reset Confirmed

Relevant, wenn die Möglichkeit zum Zurücksetzen des Nutzer-Passworts im SysConfig-Schlüssel User::Password::Reset::Enabled aktiviert ist.

  • Reagiert auf die Bestätigung der Anfrage.

  • Legt ein zufälliges Passwort für einen Kontakt/Benutzer fest und sendet es per E-Mail an den Kontakt/Benutzer.

  • Markiert das Zurücksetzen des Passworts als erledigt.

Änderungen an der Konfiguration sollten vermieden werden. Anderenfalls kann KIX den Prozess des Passwort-Resets nicht korrekt ausführen.

Password Reset Expired

Relevant, wenn die Möglichkeit zum Zurücksetzen des Nutzer-Passworts im SysConfig-Schlüssel User::Password::Reset::Enabled aktiviert ist.

  • Reagiert auf den Abschluss des Tickets, sofern die Gültigkeit des Tokens abgelaufen ist.

  • Schließt das Ticket zum Zurücksetzen des Passworts.

  • Setzt im Dynamischen Feld "PwResetState" den Status des Passwort-Resets auf "abgelaufen|expired".

Beendet somit den Vorgang zum Zurücksetzen des Passworts.

Änderungen an der Konfiguration sollten vermieden werden. Anderenfalls kann KIX den Prozess des Passwort-Resets nicht korrekt ausführen.

Password Reset Requested

Relevant, wenn die Möglichkeit zum Zurücksetzen des Nutzer-Passworts im SysConfig-Schlüssel User::Password::Reset::Enabled aktiviert ist.

  • Reagiert auf den Antrag zum Zurücksetzen des Passworts

  • Genehmigt das Zurücksetzen des Passworts

  • Erstellt für den Nutzer/Kontakt einen zeitlich begrenzten Token für das Zurücksetzen des Passworts

    Verwendet dazu den im SysConfig-Schlüssel PasswordResetToken::ExpiryTimeLimit definierte Gültigkeitsdauer.

  • Sendet den Token als Bestätigungslink per E-Mail an den Nutzer/Kontakt.

    Im Bestätigungslink sind der Verwendungskontext (Agentenportal oder Self Service Portal) und der FQDN gespeichert (s. Dynamische Felder PWResetUserID und PWResetClientFrontendFQDN).

    Tipp

    Im SysConfig-Schlüssel Http Type ist das Übertragungsprotokoll für den FQDN definiert.

    Soll anstelle des http-Protokolls das Protokoll https, verwendet werden, können Sie dies im Konfigurationsschlüssel hinterlegen.

Änderungen an der Konfiguration sollten vermieden werden. Anderenfalls kann KIX den Prozess des Passwort-Resets nicht korrekt ausführen.

Periodic Reports

Der Job ermittelt alle 15 Minuten die periodisch zu erstellenden Berichte und erzeugt diese im CSV-Format. Er bildet die Grundlage für die Aktualität der Statistiken im Home Dashboard.

Sie können die Ausführungszeiten im Job anpassen.

Wichtig

Chart Widgets - und damit die Statistiken im Home Dashboard - können nur Berichte mit Ausgabeformat CSV auswerten. In KIX Pro ist auch JSON möglich. Andere Ausgabeformate werden nicht unterstützt.

Put affected assets back into incident state

Dieser Job setzt automatisch den Vorfallstatus "Vorfall" für alle betroffenen Assets eines bestehenden Tickets wenn:

  • ein Ticket vom Typ "Vorfall" erstellt wird

  • oder der Solution-SLA noch nicht erfüllt ("satisfied") ist

  • UND eines oder mehrere Assets in "Betroffene Assets" eingetragen werden.

Achtung

Ändern Sie die Konfiguration nicht! Daran sind systemrelevante Funktionen geknüpft.

Put affected assets back into operational state

Dieser Job setzt automatisch den Vorfallstatus "Operational" für alle betroffenen Assets eines bestehenden Tickets wenn:

  • das Ticket vom Typ "Incident" geschlossen ist

  • oder der Solution-SLA erfüllt ("satisfied") ist

  • UND keine weiteren offenen/nicht gelösten Incident-Tickets zu diesem Asset existieren.

Achtung

Ändern Sie die Konfiguration nicht! Daran sind systemrelevante Funktionen geknüpft.

SLA First Response Time Fulfillment

Dieser Job setzt einen Zeitstempel in ein Ticket, wenn ein Artikel erstellt wird, der im Self Service Portal sichtbar ist. Er definiert damit den Zeitpunkt der ersten Antwort für die SLA-Erfüllung. 

Sie können den Job nach Bedarf anpassen.

Hinweis

Die Aktion "Erfüllungszeit setzen" sollte nicht entfernt werden, sonst wird der Zeitstempel nicht gesetzt.

SLA Solution Time Fulfillment

Dieser Job setzt einen Zeitstempel in ein Ticket, wenn ein Ticket den Status "entfernt", "geschlossen" oder "zusammengefasst" erhält. Er definiert damit den Zeitpunkt der Lösung für die SLA-Erfüllung.

Sie können den Job nach Bedarf anpassen.

Hinweis

Die Aktion "Erfüllungszeit setzen" sollte nicht entfernt werden, sonst wird der Zeitstempel nicht gesetzt.

SLA Time Suspension

Wichtig

Die Konfiguration des Jobs sollte nicht geändert werden!

Der Job veranlasst das Pausieren/Fortsetzen der Reaktions- und Lösungszeit am Ticket anhand des im Ticket gesetzten Status.

Welche Status dazu führen, dass Reaktions- bzw. Lösungszeit pausieren, kann beim Anlegen des SLA angegeben werden. Die im Job verwendete Macro Action SLA Criterion Suspend/Resume gleicht die Status mit dem am Ticket gesetzten Status ab und veranlasst das Pausieren/Fortsetzen der Reaktions- bzw. Lösungszeit.

Wird am pausierenden Ticket der Status geändert, verlässt das Ticket die Pause; die Zeit für das entsprechende Kriterium läuft weiter. Es erfolgt eine Neuberechnung der Zeit. Die Dauer der Pause wird zur ursprünglichen Zeit hinzugefügt.

Ticket Merge

Dieser Job wird für die initiale Ticketaktion "Zusammenfassen" benötigt. Er öffnet einen Dialog, um 2 Tickets zusammenzuführen.

Beim Speichern der Aktion wird der Job ausgelöst. Dabei wird

  • das Quellticket in den Status "merged" gesetzt

  • das Event "TicketMerge" am Quellticket ausgelöst

  • die in der Aktion konfigurierten Eigenschaften übermittelt

Wird in der Aktion der Kanal "E-Mail" oder "Notiz" gewählt, wird auch der Artikel ans Zielticket geschrieben.

Besitzt ein Ticket den Status "merged", dann werden an diesem Ticket keine admin-konfigurierbaren Ticket- und Artikelaktionen angezeigt.

Die initiale Jobkonfiguration sieht vor, dass die Ausgangstickets ans Zielticket angehängt werden. Dabei bleiben die Werte des Zieltickets bestehen und das Ausgangsticket verliert seine Werte (wie Priorität, Bearbeiter etc.).

Sie können die Aktion nachkonfigurieren und entscheiden, welche Attribute des Quelltickets mit dem Zielticket zusammengeführt werden:

  • 1. Aktion: initial "Ticket Merge" (darf nicht geändert werden)

  • Zielticket: Die Ticketnummer des Zieltickets oder der Name des dynamischen Feldes, welche die ID des Zieltickets enthält.

  • Ticket Attribute: Kommaseparierte Liste von Ticketattributen. Die Liste enthält die Attribute des Ausgangstickets, welche ans Zielticket geschrieben werden.(Achtung: Übersetzungen der Attributs-Namen sind nicht möglich).

  • Dynamische Felder: Kommaseparierte Liste der Namen der dynamischen Felder, die ans Zielticket übernommen werden (Achtung: Übersetzungen der Namen sind nicht möglich).

  • Werte für dynamische Felder erzeugen:

    • Wenn aktiviert:

      Überschreibt die Werte der aufgeführten Dynamischen Felder im Zielticket mit den Werten des Quelltickets.

    • Wenn deaktiviert:

      Der Wert eines dynamischen Feldes des Quelltickets wird am Zielticket nur gesetzt, wenn ein solcher Wert dort noch nicht vorhanden ist.

In diesem Abschnitt: