Rule Sets
Sie können das Verhalten von Eingabe- und Auswahlfeldern steuern und somit den Workflow innerhalb von Dialogen besser unterstützen. Dies erfolgt im Menü
anhand von individuell gestalteten Regelsätzen (Rulesets).Jeder Regelsatz enthält beliebig viele, frei definierbare Regeln (Rules). Die Regeln definieren die Bedingungen für das Vorhandensein und das Verhalten von Auswahl und Eingabefeldern in Ticket- und Kontakt-Formularen, Vorlagen und Aktionsdialogen.
Sie können somit bspw. steuern, dass in einem konkreten Dialog unter ganz bestimmten Voraussetzungen
Felder dynamisch ein- bzw. ausgeblendet werden
Werte in Felder gesetzt bzw. entfernt werden
nur zulässige Eingabe- und Auswahlwerte bereitstehen
ein Feld zum Pflichtfeld wird oder nicht
u.a.m.
Die Regeln wirken sich direkt auf die initialen Formular-Konfigurationen und auf die von Ihnen konfigurierten Vorlagen und Aktionsdialoge aus und beeinflussen diese. Haben Sie bspw. in einer Vorlage ein Dynamisches Feld eingebunden und blenden Sie dieses mit einer Regel aus, so wird das Dynamische Feld nicht angezeigt, auch wenn es in der Vorlage enthalten ist. Durch Angabe von Bedingungen können Sie zudem festlegen, unter welchen Voraussetzungen das Feld ausgeblendet wird. Somit können Sie das Verhalten, Aussehen und die Inhalte der Formulare/Dialoge granuliert und ganz gezielt steuern.
Achtung
Regeln können sich - je nach Konfiguration - untereinander ausschließen und miteinander kollidieren!
Bedenken Sie daher die Komplexität und arbeiten Sie im Vorfeld gewissenhaft die Regeln und Regelsätze aus, um dies zu vermeiden.
Innerhalb der Regeln können Macros aufgerufen werden, um bspw. Daten aus anderen Objekten oder Datenquellen zu beziehen und diese anschließend weiterzuverarbeiten.
Bei Auswahl von kritischen Eingabewerten kann dem Nutzer mit Dialogelementen geholfen werden. Zum Beispiel mit bestätigenden Hinweisen oder einer Anleitung für das weitere Vorgehen.
Mit Entscheidungsfragen können der weitere Fortgang des Formularausfüllens beeinflusst oder Eingaben im Dialog erfragt werden.
Die Abarbeitung der Rulesets erfolgt von oben nach unten in alphanumerischer Reihenfolge ihrer Benennung.

Abb.: Reihenfolge der Abarbeitung von Rulesets
Durch Angabe eines vorangehenden oder nachgestellten Buchstabens oder Zahl können Sie die Reihenfolge der Abarbeitung steuern, z. B.:
A_Ruleset, B_Ruleset, C_Ruleset
Ruleset1, Ruleset2, Ruleset3
1_RulesetA, 2_RulesetA, 1_RulesetB, 2_RulesetB
etc.
Wir empfehlen Ihnen, im Vorfeld eine eigene Namenskonvention zu erstellen.
Achtung
Regeln können sich - je nach Konfiguration - untereinander ausschließen und miteinander kollidieren!
Bedenken Sie daher die Komplexität und arbeiten Sie im Vorfeld gewissenhaft die Regeln und Regelsätze aus, um dies zu vermeiden.
Die in einem Ruleset definierten Regeln werden ebenfalls von oben nach unten abgearbeitet - sowohl die einzelnen Regeln im Ruleset als auch innerhalb einer Regel. Die Bezeichnung der Regeln ist für die Reihenfolge der Abarbeitung irrelevant. Es zählt die Anordnung der Regeln im Ruleset.

Abb.: Reihenfolge der Abarbeitung von Rules innerhalb eines Rulesets
Sowohl Rulesets als auch Regeln kaskadieren. D. h. wird eine Eigenschaft eines Objekts mehrfach angegeben, so gilt die zuletzt angegebene Eigenschaft (außer bei PossibleValuesAdd
und PossibleValuesRemove
).
Im nachfolgenden Beispiel gewinnt Priorität 5. Die Priorität 2 wird durch Priorität 3 ersetzt und diese wiederum wird durch Priorität 5 ersetzt.
Rule "alpha" on Ticket if TR.TypeID == 1 Set PriorityID 2 End Rule "beta" on Ticket if TR.TypeID == 1 Set PriorityID 3 End Rule "gamma" on Ticket if TR.TypeID == 1 Set PriorityID 5 End
Konfigurationsschlüssel | agent-portal-configuration |
Die Abarbeitung von Workflow-Rules erzeugt nach jeder Eingabe, die eine Regel startet, eine Eingabesperre zur Prüfung der Eingabewerte. Die Prüfung erfolgt, nachdem ein Eingabe- bzw. Auswahlfeld den Focus verloren hat.
In Multiselect-Feldern und in Dynamischen Feldern vom Typ "Tabelle" erfolgt die Prüfung nach Klick auf
. Die Eingabe des Artikelinhalts startet keine Auswertung der Workflow Rules.Das Verhalten ist nur aktiv, wenn gültige Rulesets definiert sind UND die Workflow-Evaluierung aktiviert ist. Die De-/Aktivierung der Workflow-Evaluierung erfolgt im Menü
im SysConfig-Schlüssel .
Abb.: Aktivierung Workflow-Evaluation
Ein Ruleset ist eine Liste einzelner Regeln (Rules). Jede Regel ist wie folgt aufgebaut (Teile in runden Klammern sind optional):
Rule "<Name>" (on <Object>) (if <Condition>) (<Commands>, <if-elseif-Statements>,<Macros>) End
Es gilt:
Jede Regel beginnt mit dem Schlüsselwort
Rule
.Jede Regel endet mit dem Schlüsselwort
End
.Jede Regel wird durch eine Leerzeile von der nachfolgenden Regel getrennt.
Der
<Name>
der Regelkann beliebig sein und aus mehreren Buchstaben, Wörtern und Ziffern bestehen (nutzbar, um die Regel aussagekräftig zu bezeichnen)
darf gleichlautend in mehreren Rulesets existieren, jedoch nur einmal pro Ruleset.
Regeln können optional auf ein spezifisches
<Object>
angewendet werdenaktuell auf die Objekte: Ticket und Kontakt
Schlüsselwort: on
Es können Kommentare zwischen den Regeln und zwischen den
<Commands>
geschrieben werden.Kommentare beginnen mit dem # Zeichen.
# das ist ein Kommentar zur nachfolgenden Regel Rule "hier stoppen, unter einer Bedingung" if DB.TicketID == 10 Stop End Rule "hier stoppen" on Ticket # stop here! Stop End
Mit
<if Condition>
können Bedingungen angegeben werden, die erfüllt sein müssen, damit eine Regel ausgeführt wird.<Commands>
ist eine Liste der Befehle (siehe: Befehle ).Jeder Befehl steht auf genau einer Zeile.
Zeilen können Einrückungen enthalten.
Für eine bessere Lesbarkeit können Aktionen innerhalb einer Regel durch beliebig viele Leerzeichen von den Operanden getrennt werden (s. Leerzeichen zwischen Set und Priority|StateID|Owner):
# Regel wird ausgeführt, wenn am Ticket der Typ "Störung" gesetzt wird Rule "Type" on Ticket if TR.Type eq "Incident" Set Priority "1 very high" Set StateID 2 Set Owner "mmuster" Hide DynamicFields.TestFeld End
Es können Bedingungen angegeben werden (
If-Else-EndIf
-Statements). Diese können verschachtelt werden.Rule "<RuleName>" on <Object> if <Conditions> ... If ${TR.Artikelnummer:0} == 123 && ${MyVariable3} eq "test123" Set Dummy3 ${Macro1.Parameters.DB.QueueID} If ${TR.Artikelnummer:0} != 123 Set Dummy4 "lowest if ignored" Else Set Dummy5 "else worked" EndIf End
Es können Macros ausgeführt werden, die einen Wert zurückliefern. Dieser Wert kann weiterverarbeitet werden.
Rule "SetPrio" on Ticket if TR.StateID == 1 ExecuteMacro "HoleTicket" as TicketResult with {"ObjectID":2, "SearchTicketID":1} Set PriorityID ${TicketResult.MyTicket.ticket_priority_id} End
Zum Anlegen bzw. Bearbeiten eines Rulesets, navigieren Sie im Admin Modul ins Menü Workflow > Rule Sets.
Legen Sie mit Klick auf
ein neues Ruleset an oder klicken Sie ein bestehendes Ruleset, um dieses zur Bearbeitung zu öffnen.Definieren Sie im sich öffnenden Dialog das Ruleset:

Abb.: Beispiel eines Rulesets
Feld | Beschreibung |
---|---|
Name | Tragen Sie hier eine aussagekräftige Bezeichnung für das Ruleset ein. |
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 | Notieren Sie optional einen Kommentar zum Ruleset, bspw. um dessen Funktion zu erläutern. |
Bedingung | Optional: Geben Sie eine globlale Bedingung für das gesamte Ruleset an. Das gesamte Ruleset wird nur dann ausgeführt, wenn diese Bedingung zutrifft. Mögliche Bedingungen:
Siehe auch: Einschränkung des Nutzungskontextes |
Regeln | Definieren Sie hier die einzelnen Regeln. Die Regeln können sehr gezielt und granuliert definiert werden. Berücksichtigen Sie die Reihenfolge der Abarbeitung (von oben nach unten). Beachten Sie, dass die vom System vergebenen IDs variieren können. Konfigurationsbeispiel: Rule "<Name>" on Ticket if User.isCustomer && TR.TemplateID == 3 <Commands 1,2,3> End Rule "<Name>" on Ticket if User.isAgent && TR.TemplateID == 4 <Commands 4,5,6> End |
Sie können Rulesets löschen, wenn diese nicht mehr benötigt werden.
Markieren Sie das betreffende Ruleset mit einem Häkchen
Klicken Sie auf die Schaltfläche "Löschen".
Bestätigen Sie die Sicherheitsabfrage mit "Ja", um das Ruleset endgültig zu löschen.
Danach wird das Ruleset nicht mehr angewandt.
Alle in KIX gespeicherten Daten befinden sich in der Datenbank. Wird ein Formular geöffnet, werden die Daten aus der Datenbank ausgelesen und temporär im Formular angezeigt . Im Formular können diese Daten nun geändert und um weitere Daten ergänzt werden. Erst mit dem Speichern werden die Formulardaten zurück in die Datenbank geschrieben .
Daher unterscheidet das Regelwerk zwischen:
Datenbankobjekt: die in der Datenbank bzw. im Backend bereits gesetzten (Ist-)Werte
Transaktionsobjekt: die in einem geöffneten Dialog angezeigten oder eingegebenen Werte

Abb.: Darstellung Unterschied zwischen Datenbank- und Transaktionswerten
Das bedeutet:
Sprechen Sie Werte an, die in der Datenbank oder im Backend gespeichert sind, dann verwenden Sie das Präfix
DB
.# Ist am Ticket der Tickettyp "2" (Störung) gespeichert, dann setze die Priorität auf "1" (sehr hoch) Rule "Type" on Ticket if DB.TypeID == 2 Set PriorityID 1 End
Sprechen Sie Werte an, die in einem geöffneten Formular angezeigt oder eingegeben sind, dann verwenden Sie das Präfix
TR
# Ist im geöffneten Ticket-Dialog der Tickettyp "2" (Störung) ausgewählt, dann setze Priorität auf "1" (sehr hoch) Rule "Type" on Ticket if TR.TypeID == 2 Set PriorityID 1 End
Eigenschaften des Transaktionsobjekts
Das Transaktionsobjekt kann nicht nur auf KIX-Attribute (z. B. TR.TypeID) zugreifen, sondern auch auf Vorlagen und Aktionen. Damit können Regeln derart eingeschränkt werden, dass sie nur bei Verwendung einer bestimmten Ticketvorlage (Template) oder einer Ticket-/Artikel-Aktion (ObjectAction) angewendet werden.
Dies erfolgt durch Referenz auf die ID bzw. den Namen der Vorlage/Aktion. Beachten Sie daher den in der Vorlage/Aktion gesetzten Nutzungskontext.
Wird eine Regel auf eine vom Agentenportal und Self Service Portal gemeinsam genutzte Vorlage/Aktion angewendet (Nutzungskontext Kunde + Agent), so gilt die Regel für beide Portale. Soll diese Regel jedoch nur für das Agentenportal oder für das Self Service Portal gelten, so können Sie entweder 2 separate Vorlagen/Aktionen mit jeweils anderem Nutzungskontext anlegen oder den Nutzungskontext einschränken.
Beispiel: Erweiterte Eigenschaften für Transaktionsobjekt
Rule "<Name>" on Ticket if TR.ObjectActionName eq "Ticket Edit" && TR.DynamicFields.contains(DFSelection, 1) <Commands> End Rule "<Name>" on Ticket if TR.TemplateID == 3 && TR.DynamicFields.contains(DFSelection, 1) <Commands> End
Eigenschaft | Beschreibung |
---|---|
TR.TemplateID | ID des verwendeten Templates |
TR.ObjectActionID | ID der verwendeten ObjectAction |
TR.ObjectActionName | Name der verwendeten ObjectAction Hinweis: Bei Vergleichen Operator |
Tipp
Die ID eines Objektes können Sie ermitteln, indem Sie in einer Übersicht den Mauszeiger über das gewünschte Objekt führen.
In der Fußzeile Ihres Browsers finden Sie die ID als letzten/rechten Parameter in der angezeigten URL (browserabhängig).
Mapping von Dynamischen Feldern
Die Werte von Dynamischen Feldern werden direkt an das TR.- bzw. DB.-Objekt gemappt. Sie sind somit direkt verwendbar, z. B.:
TR.MyDynamicField
DB.OtherDynamicField
Nachfolgend finden Sie die Befehle, mit denen Sie die Regeln definieren können. Wir verwenden nachfolgend Platzhalter zur Kennzeichnung von Attributen und Werten:
Platzhalter | Beschreibung | Beispiel |
---|---|---|
| | ODER-Trennzeichen Wird in der Übersicht verwendet, wenn verschiedene Möglichkeiten existieren Z. B. wenn ein Wert ODER eine Liste von Werten angegeben werden kann |
|
<Array> | Es kann ein Array von Werten angegeben werden. |
|
<Attribute> | Es kann ein KIX-Attribut angegeben werden s. auch: Übersicht der KIX-Attribute |
|
<AtttributListe> | Es kann eine Liste von Attributen angegeben werden. |
|
<Commands> | Eine Liste beliebiger Befehle. Jeder Befehl muss auf einer separaten Zeile stehen. | Rule ...
Show PriorityID
Set PriorityID 5
ReadOnly PriorityID
End |
<Condition> | Es kann der Ausdruck einer Bedingung angegeben werden. Schlüsselwort: Die Bedingung muss erfüllt sein, damit Regel ausgeführt wird. s. auch: Bedingungen (if) | Rule "<Name>" on Ticket if TR.TypeID == 2 && TR.StateID == 3
<Commands>
End |
<Count> | Numerischer Wert für eine Anzahl |
|
<ErrorMessage> | Text einer Fehlermeldung nach Prüfung der Nutzereingaben mittels RegEx |
|
<Liste> | Es kann eine Liste von Werten angegeben werden. |
|
<Name> | Der Name der Regel (alphanumerisch) Muss in Hochkommas gesetzt werden. Kann Sonderzeichen und Leerzeichen enthalten. |
|
<Object> | Es kann ein KIX-Objekt angegeben werden, auf das die Regel angewendet wird. Aktuell nur "Ticket" möglich. Schlüsselwort: s. auch: Übersicht der KIX Objekte | Rule "<Name>" on Ticket if TR.TypeID == 2
<Commands>
End |
<RegEx> | Zur Validierung von Nutzereingaben kann ein Regulärer Ausdruck angegeben werden. |
|
<Value> | Angabe des zu setzenden Wertes |
|
Schlüsselwort/ Befehl | Beschreibung | Beispiel |
---|---|---|
Stop | Die Abarbeitung der Regeln wird komplett gestoppt. Nachfolgende Regeln und Regelsätze bleiben unberücksichtigt. Mit der nächsten Nutzeraktion beginnt die Abarbeitung der Regeln von Neuem mit dem ersten Regelsatz. | Rule ... Stop End |
Die Verwendung von Operatoren ermöglicht das Verknüpfen und Vergleichen von Bedingungen. Nachfolgend die wichtigsten Perl-Operatoren.
Beispiel für den Operator UND (&&)
# Sind am Ticket der Tickettyp "3" (Service Anfrage) UND der Status 3 (Warten) gewählt, dann setze die Priorität auf "4" (niedrig) Rule "Type" on Ticket if TR.TypeID == 2 && TR.StateID == 3 Set PriorityID 4 End
Operator | Beschreibung | |
---|---|---|
1. Rang | 2. Rang | |
&& | and AND | Stellt eine logische UND-Verknüpfung zwischen 2 Argumenten her. Regel wird ausgeführt, wenn beide Argumente wahr sind. |
|| | or OR | Stellt eine logische ODER-Verknüpfung zwischen 2 Argumenten her. Regel wird ausgeführt, wenn eins der beiden Argumente wahr ist. |
== | eq | Vergleichsoperator "ist gleich" Vergleicht 2 Werte. Gibt
|
!= | ne | Vergleichsoperator "ist ungleich" Vergleicht 2 Werte. Gibt
|
Tipp
Weiterführende Informationen zu Perl-Operatoren finden Sie bspw. unter: https://de.wikibooks.org/wiki/Perl- Programmierung:_Operatoren
Das Schlüsselwort if
definiert eine WENN-Bedingung. Diese muss erfüllt sein (true
), damit die in der Regel angegebenen Befehle abgearbeitet werden.
Ist keine Bedingung angegeben, wird die Regel in jedem Fall ausgeführt.
Beispiel für eine einfache if-Bedingung:
# Wenn die TicketID gleich 10 ist, dann Ausführung der Regel stoppen
Rule "hier stoppen" if DB.TicketID == 10
Stop
End
Schlüsselwort/ Befehl | Beschreibung | Beispiel |
---|---|---|
DB.<Attribute> | Abarbeitung erfolgt auf Grundlage der Datenbankwerte (Datenbankobjekt) | Rule "<Name>" if DB.TypeID == 1
<Commands>
End |
TR.<Attribute> | Abarbeitung erfolgt auf Grundlage der Transaktionswerte (Transaktionsobjekt) | Rule "<Name>" if TR.TypeID == 1
<Commands>
End |
if !Rule "<Name>" ... | Prüft, ob eine bestimmte Regel NICHT angewendet wurde. | Rule "<Name>" if !Rule "<RuleName>"
<Commands>
End |
if Rule "<Name>" ... | Prüft, ob eine bestimmte Regel angewendet wurde. | Rule "<Name>" if Rule "<RuleName>"
<Commands>
End |
if <Attribute>.isEmpty(<Feld>) | Prüft, ob ein Feld keinen Wert oder eine leere Liste besitzt Hinweis: | Rule "<Name>" if TR.DynamicFields.isEmpty(Category)
<Commands>
End |
if !<Attribute>.isEmpty( <Feld>) | Prüft, ob ein Feld irgendeinen Wert oder keine leere Liste besitzt. Achten Sie darauf, das Ausrufezeichen an den Anfang der Bedingung zu setzen. | Rule "<Name>" if !TR.DynamicFields.isEmpty(Category) <Commands> End |
if<Attribute>.contains(<Feld>,<Wert- Liste>) | Prüft, ob irgendeiner der angegebenen Werte in einem Feld enthalten ist. Es kann eine Liste von Werten angegeben werden. | Rule "<Name>" if TR.DynamicFields.contains(Category,[1,2,3,23])
<Commands>
End |
Tipp
Durch Kombination von if Rule
mit if !Rule
kann ein einfaches IF - ELSEIF - ELSE
erzeugt werden:
Rule "alpha" on Ticket if TR.ObjectActionName eq "Ticket Edit" <Commands> End Rule "beta" if Rule "alpha" Show DynamicFields.DFText End Rule "gamma" if !Rule "alpha" Hide DynamicFields.DFText End
Die Prüfung von Bedingungen (Conditions) kann sowohl auf eine Objekt-ID auch auf den jeweils eindeutigen Namen von Objekten erfolgen. Akzeptiert werden die Namen für:
Team/Queue: der volle Team-/Queuename (z.B. "Service Desk")
Rule "Queue" on Ticket if TR.Queue eq "Service Desk" Set Priority "1 very high" Set State "new" Set Type "Incident" Set Owner "mamu" Set Responsible "mamu" Set Contact "max.mustermann@example.org Set Organisation "MY_ORGA" End
Bei untergeordneten Teams muss auch das übergeordnete Team angegeben werden. Verwenden Sie doppelte Doppelpunkte als Trennzeichen: z. B. "MainTeamA::SubTeamA1")
State: der Name des Status
Priority: der Name der Priorität
Type: der Name es Tickettyps
Owner: der Login-Name des Nutzers
Responsible: der Login-Name des Nutzers
Contact: die Mailadresse (ohne Realname, nur "localpart@domainpart")
Organisation: die Kundennummer
Mehrere Bedingungen können miteinander kombiniert werden, indem sie in Klammern gesetzt werden:
Rule "ProzessStatus" on Ticket if (TR.ObjectActionName eq "Freigabe" || TR.ObjectActionName eq "Planung") && (TR.QueueID == 1 || TR.QueueID == 2 || TR.QueueID == 3) && TR.DynamicFields.contains(DFChiffre, "C4711-08A15") <Commands> End
Bedingungen können als RegEx angegeben werden:
Rule "Show Dynamic Field" on Ticket if TR.ObjectActionName =~ /^(Ticket Edit|Ticket New Article)$/ && TR.Queue =~ /^(Service Desk|.*Monitoring)$/ Show DynamicFields.DynamicFieldName Enable DynamicFields.DynamicFieldName End
Anweisungen sind ein einzelner Befehl oder eine Liste von Befehlen innerhalb einer Regel. Sie folgen auf eine WENN-Bedingung (if
) und entsprechen einem then
-Statement gemäß folgender Aussage: WENN eine bestimmte Bedingung erfüllt ist, DANN führe folgenden Befehl/folgende Befehle aus.
Jede Zeile enthält genau eine Anweisung. Die Anweisungen werden in der angegebenen Reihenfolge von oben nach unten abgearbeitet.
Beispiel: Liste von Anweisungen
# Ist die Ticket ID gleich 10, # - DANN: Zeige das Feld Priorität an # - DANN: Setze die Priorität 3 (Normal) # - DANN: Stoppe die Abarbeitung der Regeln Rule "hier stoppen" if DB.TicketID == 10 Show PriorityID Set PriorityID 3 Stop EndRule "hier stoppen" if DB.TicketID == 10 Show PriorityID Set PriorityID 3 Stop End
Bedingungen innerhalb von Anweisungen
Das Schlüsselwort If
schließt innerhalb einer Regel einen Block von Anweisungen in eine Bedingung ein. Als Bedingung wird alles betrachtet, was auf das Schlüsselwort folgt - bis zum Ende der Zeile.
Anmerkung
Die Bedingung am If
-Statement muss auf einer Zeile definiert werden.
If
-Statements können beliebig oft in einer Regel enthalten sein.Mit dem Schlüsselwort
Else
können Sie Verzweigungen in der Bedingung erzeugen.If-Else-EndIf
-Statements ermöglichen die bedingte Ausführung von Anweisungen (WENN...DANN...SONST... ENDE).Eine Verschachtelung der Anweisungen ist möglich.
Beispiel für verschachtelte Bedingungen:
Rule "<RuleName>" on <Object> if <Conditions> ... If ${MyVariable3} eq "test123" Set Dummy2 ${Macro1.Parameters.TR.QueueID} If ${TR.Artikelnummer:0} == 123 && ${MyVariable3} eq "test123" Set Dummy3 ${Macro1.Parameters.DB.QueueID} If ${TR.Artikelnummer:0} == 123 Set Dummy4 "lowest if" EndIf If ${TR.Artikelnummer:0} != 123 Set Dummy4 "lowest if ignored" Else Set Dummy5 "else worked" EndIf EndIf Else Tell Error "Error!" "Some error occured" EndIf End
Der Befehl SetVariable
setzt eine Variable während der Ruleset-Evaluierung.
Es steht die gesamte Variablen-Funktionalität zur Verfügung, die auch in Macros genutzt werden kann. Zudem stehen auch die Datenstrukturen "TR" und "DB" als Variablen zur Verfügung.
Syntax: SetVariable <Variablenname> <Wert>
Beispiel: SetVariable MyVar1 "test123"
Hinweis
Der Wert wird bei der späteren Ersetzung 1:1 eingefügt, d.h. inkl. Anführungszeichen u.ä.
Für Ticketvorlagen und Aktionen, die vom Agentenportal und Self Service Portal gemeinsam genutzt werden (Nutzungskontext Kunde + Agent), können Sie getrennte Regeln erstellen. Es ist somit möglich, die Ausführung von Regeln auf den jeweiligen Nutzungskontext einzuschränken. Die Einschränkung erfolgt durch Angabe der Eigenschaft des Nutzers:
User.isCustomer: Regel wird auf das Self Service Portal angewendet.
User.isAgent: Regel wird auf das Agentenportal angewendet.
Im folgenden Beispiel wird die Ticketvorlage mit der ID 3 vom Agentenportal und Self Service Portal gemeinsam genutzt. Je nach dem, in welchem Portal die Vorlage genutzt wird, gelten unterschiedliche Regeln.
#Regel für Ticketvorlage 3 wird auf den Nutzungskontext 'Customer' (Self Service Portal) eingeschränkt: Rule "UsageContext Customer" on Ticket if User.isCustomer && TR.TemplateID == 3 && TR.DynamicFields.contains(DFSelectionSingle, 1) <Commands 1,2,3> End #Regel für Ticketvorlage 3 wird auf den Nutzungskontext 'Agent' (Agentenportal) eingeschränkt: Rule "UsageContext Agent" on Ticket if User.isAgent && TR.TemplateID == 3 && TR.DynamicFields.contains(DFSelectionSingle, 2) <Commands 4,5,6> End
Schlüsselwort/Befehl | Beschreibung | Beispiele |
---|---|---|
PossibleValues <Attribute> <Liste> | Definiert die möglichen Werte in einem Feld. Nur die hier angegebenen Werte können in ein Feld gesetzt werden. Werte, die Buchstaben enthalten müssen in einfache oder doppelte Hochkommas gesetzt werden ( "Text" oder 'Text' ). Dynamische Felder erwarten stets den Key und nicht den Wert. | Rule "Tickettyp Incident" on Ticket if TR.TypeID == 2
PossibleValues PriorityID 1,2,3
End |
PossibleValuesAdd <Attribute> <Liste> | Fügt einem Feld die angegebenen Werte hinzu. Ergänzt damit bspw. weitere Auswahlwerte in einem Selectfeld, wenn zuvor die möglichen Auswahlwerte mit Hinweis: Wird der Befehl mehrfach verwendet, so werden die zuvor definierten Werte nicht ersetzt, sondern ergänzt (= Kombination der Befehle)! | Rule "Tickettyp Incident" on Ticket if TR.TypeID == 2
PossibleValuesAdd PriorityID 4,5,6
End |
PossibleValuesRemove <Attribute> <Liste> | Entfernt die angegebenen Werte aus einem Feld. Reduziert damit bspw. die möglichen Auswahlwerte in einem Selectfeld, wenn die möglichen Auswahlwerte zuvor mit "PossibleValuesAdd" erweitert wurden. Hinweis: Wird der Befehl mehrfach verwendet, so werden die zuvor definierten Werte nicht ersetzt, sondern ergänzt (= Kombination der Befehle)! | Rule "Tickettyp Unclassified" on Ticket if TR.TypeID == 1
PossibleValuesRemove StateID 4
End |
Hinweis
Für die Commands PossibleValues
, PossibleValuesAdd
, PossibleValuesRemove
, und Set
müssen Zeichenketten in doppelte Anführungszeichen eingeschlossen ein.
Es können Kommas innerhalb einer Zeichenkette enthalten sein. Diese gelten nicht als Trennzeichen der Werteliste.
Beachten Sie, dass sich einige der nachfolgenden Befehle ausschließen.
So kehrt bspw. der Befehl Hide
den Befehl Show
um. Das heißt, wird ein Feld mit Show
angezeigt und danach ein Hide
auf das Feld angewendet, so beendet das die Anzeige des Feldes. Der letzte Befehl gewinnt.
Schlüsselwort/ Befehl | Beschreibung | Beispiel |
---|---|---|
MinSelectable <Attribute> <Count> | Definiert die Anzahl der Werte, die der Nutzer mindestens auswählen muss, z. B. mindestens 2 von n Werten. | Rule ... MinSelectable DynamicFields.DFSelection 2 End |
MaxSelectable <Attribute> <Count> | Definiert die Anzahl an Werten, die der Nutzer maximal auswählen darf, z. B. maximal 2 von n Werten; danach ist keine weitere Auswahl möglich (x<=n) | Rule ... MaxSelectable DynamicFields.DFSelection 2 End |
Set <Attribute> "<Value>|<Liste>|<Array>" | Setzt einen festen Wert in ein Feld. Erlaubt optional eine Liste von Werten oder ein Array. Zeichenketten müssen in doppelte Hochkommas gesetzt werden. Die Kombination von Zeichenketten und Werten ist möglich - sofern vom Attribut unterstützt. Wird in einer Regel ein Parameter mehrfach angegeben (bspw. als Queue oder QueueID), so gewinnt der letzte Eintrag. Der Parameter unterstützt neben den ObjektIDs auch die Namen von Objekten. Akzeptiert werden für:
| Rule ... Set PriorityID 5 Set State "New" Set Owner "mamu" Set OrganisationID 2,5,10 Set DynamicFields.DFText "foo", "foo bar", "foo, bar & 2 foobar" Set DynamicFields.DFDateTime "2022-09-01 12:34:56" End |
ReadOnly <Attribute> | Feld wird auf "nur Lesen" gesetzt. Gegenstück und Umkehr des Befehls | Rule ... Set PriorityID 5 ReadOnly PriorityID End |
Writable <Attribute> | Feld wird auf "änderbar" gesetzt. Gegenstück und Umkehr des Befehls | Rule ... Writable DynamicFields.DFText End |
Clear <Attribute> | Ein im Feld gesetzter Wert wird entfernt. | Rule ... Clear DynamicFields.DFSelection End |
Show <Attribute> | Feld wird angezeigt/nicht versteckt Gegenstück und Umkehr des Befehls | Rule ... Show PriorityID End |
Hide <Attribute> | Feld wird versteckt (ausgeblendet). Gegenstück und Umkehr des Befehls Hinweis: Ausgeblendete Felder sind weiterhin aktiv und werden beim Speichern berücksichtigt. Das heißt:
Damit ein Feld beim Speichern nicht berücksichtigt wird, muss es mit | Rule ... Hide PriorityID End |
Enable <Attribute> | Setzt ein Feld auf "aktiv", sodass es entsprechend seiner Konfiguration normal verwendet werden kann. Gegenstück und Umkehr des Befehls Ist das Feld versteckt, wird ein (im Hintergrund) gesetzter Wert übertragen. Benötigt zusätzlich den Befehl Wichtig!: Führen Sie das | Rule ... Show DynamicFields.DFText CountMax DynamicFields.DFText 3 Enable DynamicFields.DFText End |
Disable <Attribute> | Feld wird deaktiviert und im Frontend ausgeblendet (= implizites "Hide"). Wert wird NICHT im Hintergrund übertragen Gegenstück und Umkehr des Befehls | Rule ... Disable DynamicFields.DFText End |
Optional <Attribute> | Feld ist optional, d.h. kein Pflichtfeld Gegenstück und Umkehr des Befehls | Rule ... Optional DynamicFields.DFTextArea End |
Required <Attribute> | Das Feld ist ein Pflichtfeld Gegenstück und Umkehr des Befehls | Rule ... Required DynamicFields.DFTextArea End |
Schlüsselwort/Befehl | Beschreibung | Beispiel |
---|---|---|
CountMax <Attribute <Count> | Setzt für die Eigenschaft "Anzahl (min)" eines Dynamischen Feldes einen (anderen) Wert. Hinweis: | Rule ... CountMax DynamicFields.DFText 3 End |
RegExp <Attribute> "<RegEx>" "<ErrorMessage>" | Regulärer Ausdruck zur Validierung der Nutzereingaben (RegEx) in einem Feld und Text für Fehlermeldung bei invalider Eingabe (ErrorMessage). Z. B. Bedingungen für die Eingabe einer validen IP4- und IP6-Adresse | Rule ... Show DFText RegExp DFText "((^\s*((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))\s*$)|(^\s*((([0-9A-Fa-f]{1,4}:){7}([0-9A-Fa-f]{1,4}|:))|(([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}|((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){5}(((:[0-9A-Fa-f]{1,4}){1,2})|:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){4}(((:[0-9A-Fa-f]{1,4}){1,3})|((:[0-9A-Fa-f]{1,4})?:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){3}(((:[0-9A-Fa-f]{1,4}){1,4})|((:[0-9A-Fa-f]{1,4}){0,2}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){2}(((:[0-9A-Fa-f]{1,4}){1,5})|((:[0-9A-Fa-f]{1,4}){0,3}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){1}(((:[0-9A-Fa-f]{1,4}){1,6})|((:[0-9A-Fa-f]{1,4}){0,4}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(:(((:[0-9A-Fa-f]{1,4}){1,7})|((:[0-9A-Fa-f]{1,4}){0,5}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:)))(%.+)?\s*$))" "Gib eine gültige IP Adresse ein" End |
InputOrder <AttributeList> | Definiert die Reihenfolge der Felder im Formular, z. B.: 1. Feld: Priorität 2. Feld: Status 3. Feld: Dynamisches Feld "DFText" Die benannten Felder werden in angegebener Reihenfolge ganz nach oben an den Anfang des Formulars gesetzt. Alle weiteren Formularfelder werden darunter angeordnet, gemäß der im Template definierten Reihenfolge. | Rule ... InputOrder PriorityID, StateID, DynamicFields.DFText End |
Die Funktion Tell
definiert eine Interaktion mit dem Nutzer in Form eines Popups. Sie wird verwendet, um den Nutzer über etwas zu informieren (z. B. über bereits existierende Datensätze).
Syntax: Tell <Severity> "<Title>" "<Message >"
Severity: Definiert die Art des Hinweises. Unterstützt werden:
Info
Warning
Error
Title: Titel in der Kopfzeile des Popups
Message: Der anzuzeigende Benachrichtigungstext
Die Verwendung von HTML-Tags wird unterstützt.
Beispiel: Tell Info "This is a test" "Hi, there, <br/><br/> we are testing someting."
Anmerkung
Werden mehrere Tell
-Befehle ausgeführt, so werden diese in der Reihenfolge ihrer Ausführung nacheinander in der GUI angezeigt.
Die Funktion Ask
definiert eine Interaktion mit dem Nutzer in Form eines Popups. Sie wird zur Abfrage einer Nutzer-Entscheidung verwendet.
Syntax: Ask "<Title>" "<Question > as <Identifier> with <OptionList>"
Title: Titel in der Kopfzeile des Popups
Question: Text der Frage
Identifier: Identifikator der Frage. Enthält die Antwort auf die gestellte Frage.
OptionList: Kommaseparierte Liste, deren Elemente jeweils aus
Wert
undLabel
bestehen. Diese werden per Gleichheitszeichen (=) voneinander getrennt.Beispiel:
<Wert>=<Label>
Klickt der Nutzer eine Antwort, so erfolgt eine erneute Evaluierung der Rulesets. Die Antwort ist über TR.Answers.<Identifier>
in den Conditions verfügbar. Der Wert ist dann der Key der vom Nutzer gewählten Option.
Beispiel: Ask "A question" "Know what?" as Question1 with 0=No, 1=Yes, 2=Don't know
Anmerkung
Werden mehrere Ask
-Befehle ausgeführt, so werden diese in der Reihenfolge ihrer Ausführung nacheinander in der GUI angezeigt. Die erneute Ruleset-Evaluierung erfolgt erst nach Beantwortung aller Fragen.
Der Submit-Button (i.d.R. Enable
bzw. Disable
de-/aktiviert werden. Dies ermöglicht bspw. das Deaktivieren der -Schaltfläche, solange die eingegebenen Daten nicht korrekt sind.
Beispiel: Disable Submit
oder Enable Submit
DynamicFields.contains
Mit der Funktion DynamicFields.contains
kann überprüft werden, ob an einem Dynamischen Feld ein bestimmter Wert gesetzt ist.
Die Funktion sucht in der Liste der Dynamischen Felder nach dem Namen des Dynamischen Feldes und prüft, ob der angegebene Wert in den Werten des Dynamischen Feldes enthalten ist.
Wenn ja, liefert die Funktion 1 zurück
Wenn nein, liefert die Funktion 0 zurück.
Es kann stets nur 1 Wert abgefragt werden. Werden mehrere Werte des selben Feldes abgefragt, müssen weitere Regeln oder Bedingungen erstellt werden.
Zeichenketten müssen in Hochkommas gesetzt werden. Es wird nach genau nach dem angegebenen Begriff gesucht. Groß- und Kleinschreibung wird beachtet, z. B.:
Datenbankobjekt:
DB.DynamicFields.contains(<DFName>, <"Zeichenkette">)
Transaktionsobjekt:
TR.DynamicFields.contains(<DFName>, <"Zeichenkette">)
Numerische Werte, z. B. Auswahlwerte in Selectfeldern, erwarten keine Hochkommas.
Datenbankobjekt:
DB.DynamicFields.contains(<DFName>, <DFWert>)
Transaktionsobjekt:
TR.DynamicFields.contains(<DFName>, <DFWert>)
Beispiel für DynamicField.contains
Rule "Alpha" on Ticket if TR.DynamicFields.contains(DFSelectionSingle, 0) MaxSelectable DynamicFields.DFSelectionMulti 1 PossibleValues DynamicFields.DFSelectionMulti 0,1,2 End Rule "Beta" on Ticket if TR.DynamicFields.contains(DFSelectionSingle, 2) MaxSelectable DynamicFields.DFSelectionMulti 1 PossibleValues DynamicFields.DFSelectionMulti 3,4,5 End Rule "Gamma" on Ticket if TR.DynamicFields.contains(DFSelectionSingle, 2) MaxSelectable DynamicFields.DFSelectionMulti 1 PossibleValues DynamicFields.DFSelectionMulti 6,7,8,9 End Rule "Delta" on Ticket if TR.DynamicFields.contains(DFText, "Hinweis") Required DynamicFields.DFTextArea Show DynamicFields.DFTextArea Enable DynamicFields.DFTextArea End