Übersicht der Macro Actions
Nachfolgend finden Sie eine Übersicht der mit KIX ausgelieferten Macro Actions zur Verwendung in Jobs oder Aktionen.
Tipp
Einige der Macro Actions bieten einen Editor zum Hinterlegen von Text an (z. B. Ticket anlegen oder Artikel erstellen). Wenn Sie KIX Platzhalter via Copy & Paste im Editor einfügen, werden diese aufgrund der spitzen Klammern nicht anerkannt. Verwenden Sie daher zum Einfügen von KIX Platzhaltern die Tastenkombination STRG + SHIFT + V bzw. COMMAND+ SHIFT + V.
Fügt einem bestehenden Artikel einen Dateianhang hinzu.
In Verbindung mit der Macro Action "Convert to PDF" können PDF Dateien unmittelbar bei Erstellung eines Artikels generiert und diesem beigefügt werden (z. B. Ausdruck der von der KIX Field Agent App erzeugten Arbeitsberichte).

Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
ArticleID | Definiert, an welchem Artikel der Dateianhang erzeugt werden soll Z. B. der jeweils aktuelle Artikel: <KIX_ARTICLE_ArticleID> |
Attachment | Definiert welche Datei angehängt wird Z. B. ein mit der Macro Action "Convert to PDF" erstelltes PDF eines Tickets bzw. Artikels |
Setzt E-Mail-Attribute (Bcc, Cc, An, Von).
Kann für die Anonymisierung verwendet werden.
Anzugeben sind jeweils gültige E-Mail-Adressen. Die Verwendung von KIX Platzhaltern ist möglich.
Verwendung/Jobtyp: Ticket
Legt einen Artikel mit vordefinierten Inhalten an.
Verwendung/Jobtyp: Ticket
Die in der Macro Action anzugebenden Parameter entsprechen denen zum Anlegen eines neuen Artikels.
Zusätzliche Parameter sind:
Parameter | Beschreibung |
---|---|
Überspringen | Wenn aktiviert: Überspringt die Ausführung der Aktion |
NewArticleID | Ergebnisvariable. Individueller Bezeichner zum Speichern der Artikel ID (z. B. myArticleID). Über diese Variable kann auf den Artikel in nachfolgenden Macro Actions referenziert und deren Wert verwendet werden. |
DoNotSendEmail | Wenn aktiviert, wird das Versenden des neuen Artikels durch das System verhindert. So kann bspw. bei Kopplung von 2 Systemen verhindert werden, dass das Empfängersystem den Artikel noch einmal versendet, obwohl das Sendersystem dies bereits getan hat. |
Anhangsobjekt | Optional: Angabe eines Anhang-Objektes mit den Attributen Es ist der Bezeichner der Ergebnisvariable anzugeben. Z. B.: Anhang-Objekte können mit der Macro Action Objekt zusammenstellen oder Konvertieren zu PDFerstellt werden. Anwendungsbeispiel: Berichte automatisiert erstellen |
Dynamische Felder | Setzen von Dynamischen Feldern am Artikel
HinweisEin Dynamisches Feld mit Objekttyp "Article" steht nur dann am Artikel zur Verfügung, wenn ein Kanal ausgewählt wurde. |
Hinweise:
Verwendung der ArtikelID s. Variablen
Soll ein mehrzeiliger Text (DF Typ "TextArea") in einen Artikel eingefügt werden, so müssen Sie das Suffix "_HTML" verwenden, um Zeilenumbrüche zu erhalten. Zum Beispiel: <KIX_TICKET_DynamicField_WorkOrder_HTML>
Löscht den durch die ArticleID identifizierten Artikel.
Die Historie am Ticket erhält den Eintrag, dass der Artikel gelöscht wurde.
Verwendung/Jobtyp: Ticket
Parameter | Hinweise |
---|---|
ArticleID | ID des zu löschenden Artikelswerden soll. Es können Platzhalter verwendet werden (z. B.: <KIX_LAST_ArticleID> ) |
Hinweise:
Das Löschen fungiert im Hintergrund; bei Jobs also mit den Berechtigungen des Systemusers.
Es gelten damit nicht die Rollenberechtigungen des auslösenden Nutzers wenn die Macro Action verwendet wird.
Die Aktion "ArticleDelete" verwendet ebenfalls diese Macro Action.
Referenziert auf ausgewählte Asset Attribute, um diese bspw. in den Ticketinformationen anzuzeigen.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Assetbezug aus dynamischen Feld: | Referenz zum Asset, dessen Attribute abgerufen werden sollen. Geben Sie den Namen des Dynamischen Felds an, welches die ID des zu verwendenden Assets enthält, z. B. AffectedAsset oder RelatedAssets. Beispiel: Sollen Attribute des am Ticket ausgewählten "betroffenen Assets" ausgelesen werden, so tragen Sie hier "AffectedAsset" ein. |
Attribut - Dynamisches Feld Mapping: | Definiert, welches Asset Attribut in welchem Dynamischen Feld angezeigt wird. Beispiel: Liest den Hersteller des Assets aus und zeigt diesen im Dynamischen Feld "DFHersteller" an.
(Der Wert des Dynamischen Feldes "DFHersteller" wird dort angezeigt, wo es in der Oberfläche eingebunden ist.) |
Praxisbeispiele: Asset Attribute in den Ticketdetails anzeigen und Services in den Ticketdetails anzeigen
Aktualisiert ein bestehendes Asset (inkl. neuer Version), wenn eine Asset ID angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.
Legt ein neues Asset (inkl. Versionsdaten) an, wenn keine Asset ID angegeben ist.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Die Macro Action kann bspw. verwendet werden:
um die aufbereitete Rückgabe eines Webhook-Aufrufs zur Anlage bzw. Aktualisierung eines Assets zu nutzen
um bei Erreichen eines Ticketzustands das/die referenzierte/n Asset/s mit Angaben aus dem Ticket (oder absoluten Werte) zu aktualisieren
um den Automatismus auf beliebige Dynamische Felder vom Typ "AssetReference" bei bestimmten Ereignissen oder zeitlich gesteuert anzuwenden.
Konkrete Anwendungsfälle wären zum Beispiel:
Mit KIXConnect: Eine periodische Anfrage an eine Webservice-Schnittstelle liefert Angaben zu einem Asset zurück. Diese Daten sollen zur Aktualisierung der Eintragung im KIX-Assetmanagement genutzt werden können ( => Baramundi-Inventarisierung; => IDoIT-Inventarisierung; etc.)
Ohne KIXConnect:
An einem Ticket wird die Auslieferung von N Assets in einem Dynamischen Feld vom Type Date/Time dokumentiert. An den betroffenen Assets soll der Tag der Inbetriebnahme mit diesem Wert gesetzt und der Verwendungsstatus auf "Produktion" gesetzt werden.
An einem Ticket zu einem Servicevertrag werden Zeiteinheiten verbucht. Am Asset Servicevertrag wird das verbrauchte Budget geführt. Bei Ticketabschluss soll das verbrauchte Budget am Asset um die Summe der Zeitaufwände am Ticket erhöht werden.
An einem Ticket wird der km-Stand eines Kfz erfasst. Das Kfz ist als Asset erfasst und beinhaltet den zuletzt abgelesenen Kilometerstand. Dieser soll automatisch aus dem Ticket in das Asset geschrieben werden.
An einem Ticket zum Austausch eines Arbeitsplatzrechners wird das Altgerät und das Neugerät eingetragen. Mit Erreichen eines Bearbeitungsstatus "ausgetauscht", wird die Nutzerzuordnung des Altgeräts entfernt und der Nutzer am Austauschgerät eingetragen. Der Nutzer ist Kundenkontakt des Tickets.
Parameter | Beschreibung |
---|---|
AssetID | Ergebnisvariable Die ID des zu aktualisierenden Assets. Die Angabe bestimmt, ob Update oder Create des Assets erfolgt.
Ist keine Asset ID angegeben, wird ein neues Asset angelegt. Tipp: Die ID des Assets können sie der Adress- oder Fußzeile des Browsers entnehmen. |
VersionID | Ergebnisvariable. Die ID der neuen Version. |
Überspringen | Ermöglicht temporäres Deaktivieren der Aktion. |
Asset JSON Objekt | JSON-Editor zum Hinterlegen der Konfiguration. Möglich ist die Verwendung einer |
Wert der Vorversion übernehmen | Legt fest, wie mit Leerwerten verfahren wird (analog Import von Assets). Wenn ausgewählt, werden nicht enthaltene Angaben aus vorherigen Versionen übernommen. |
Die Macro Action erwartet eine Konfiguration im JSON-Format. In der Konfiguration wird definiert, welches Asset von welcher Asset-Klasse angesprochen wird und welche Attribute dieses Assets mit welchen Werten belegt werden.
Zum Beispiel ein PC mit der Asset ID 4 in der Asset-Klasse Computer. An diesem PC können über die Macro Action der Vorfallstatus und der Verwendungsstatus gesetzt werden sowie ausgewählte Attributwerte am Asset, bspw. das Datum der Inbetriebnahme.
Der grundlegende Aufbau des JSON orientiert sich an einem POST-Request für ConfigItems/Assets (ohne Images).
Das Verhalten der Macro Action entspricht dem CSV-Import von Assets.
Ergebnisse der Macro Action: AssetID und VersionsID.
Bei Datumsangaben muss im CI und im Dynamischen Feld, dessen Wert ins Asset übertragen wird, der Feldtyp "DateTime" benutzt werden. Der Feldtyp "Date" funktioniert nicht.
Die Verwendung von KIX Platzhaltern für Asset-Attribute ist möglich.
{ "AssetID": 1, "ClassID": 4, "Version": { "Name": "some name", "DeplStateID": 16, "InciStateID": 1, "Data": {} } }
AssetID
: ID des zu aktualisierenden AssetsUpdate: wenn Asset ID angegeben ist
Create: wenn keine Asset ID angegeben ist
ClassID
: ID der Asset-Klassez. B.: "4" für die Assetklasse Computer
Angabe ist Pflicht bei "Create"; optional bei "Update"
Name
: Name des AssetsAngabe ist Pflicht bei "Create"; optional bei "Update"
DeplSateID
: ID des Verwendungsstatuswenn nicht angegeben:
bei Create: Default zu Produktion
bei Update: Werte der vorherigen Version
InciStateID:
ID des Vorfallstatuswenn nicht angegeben:
bei Create: Default zu Operational
bei Update: Werte der vorherigen Version
Data{...}
:Die unter Data{...} angegebenen Attribute sprechen die Asset-Attribute in der Klassendefinition an. Hier wird definiert, welche Werte an welchem Attribut der Klassendefinition gesetzt werden. Die Angaben können auf 3 Arten erfolgen:
Direkt (Wert nach dem Attributs-Key)
{ "Version": { "Data": { "SomeAttribute": "Value" } } }
Direkt (Wert-Liste (Array) nach dem Attributs-Key)
{ "Version": { "Data": { "SomeAttribute": [ "Value1", "Value2" ] } } }
Als Objekt-Liste (Array of "Hashes") nach dem Attributs-Key. Wobei der Attributs-Key selbst darin enthalten ist und dieser den Wert wiederum direkt erhalten muss.
Diese Variante muss genutzt werden, wenn man Kind/Sub-Attribute angeben will. Die Kind/Sub-Attribute können dann wiederum eine der Varianten nutzen.
{ "Version": { "Data": { "SomeAttribute": [ { "SomeAttribut": "Value1", "SomeChildAttribute": "ChildValue" }, { "SomeAttribut": "Value2" } ] } } }
Es ist möglich, die zuvor genannten Varianten 2 und 3 zu kombinieren: Wird in Variante 3 bei allen Werten (direkt in der Liste, ohne Kinder) ein Objekt/Hash angegeben, kann anstatt des Hashs für den 2. Wert direkt ein "Value2" - wie in der 2. Variante - angegeben werden.
Anhänge (Attachments) sind möglich . Der Wert ist - wie in der API üblich: Object mit "Filename", "ContentType" und base64-codiertem "Content"
Der Inhalt von Data muss nicht die komplette Versions-Definition umfassen, ein einzelnes Attribut ist ausreichend. Attribut-Werte müssen - soweit notwendig - IDs sein (wie bei POST). Es findet keine "Auflösung" der Werte statt (z. B. bei GeneralCatalog-Attributen).
Bei Datumsangaben muss im CI und im Dynamischen Feld, dessen Wert ins Asset übertragen wird, der Feldtyp "DateTime" benutzt werden. Der Feldtyp "Date" funktioniert nicht.
Nicht angegebene Attribute werden ignoriert; deren Werte bleiben unverändert.
Der Code erwartet im "Version"-Objekt mindestens eine Angabe (Name, DeplState oder InciState). Die "Data"-Angaben sind optional.
Die Verwendung von KIX-Platzhaltern ist überall möglich. Nicht auflösbare Platzhalter werden mit einem Leerstring ersetzt.
Statt einem "JSON-Object"-String kann auch ein "Result"-Platzhalter verwendet werden ( $ {SomeAssembledObject}
). Dieser wird zwar vom Editor als falsch gekennzeichnet (da kein valides JSON), aber dennoch akzeptiert.
Als Result-Variablen werden gesetzt: "AssetID" - ID des erstellten/aktualisierten Assets "VersionID" - ID der neuen Version
.
Die Option Wert der Vorversion übernehmen bestimmt, wie mit leeren Attribut-Werten (null, Leerstrings) umgegangen werden soll (analog CSV-Import von Assets). Nicht angegeben Attribut-Werte werden generell ignoriert, d. h. sie haben keine Auswirkung auf Alt-Werte. Standardmäßig ist die Checkbox im Frontend angehakt (aktiv).
Beispiel
Variante A: Das Asset hat im Attribut bereits 2 Werte
Variante B: Das Asset hat im Attribut bereits 5 Werte
Folgendes JSON wird angewendet:
{ "SomeAttribute": [ null, null, null, "NewValue" ] }
Wenn die Option aktiviert ist: Neue Werte werden "angehangen" oder überschreiben an selber Wert-Position.
In Variante A: "NewValue" wird als 3. Wert abgelegt. 1. und 2. Wert bleiben erhalten, da der Leerwert die alten Werte belässt. Einen 3. Wert gab es nicht, also ist dieser Platz frei (Vermeidung leerer Wert- Plätze).
In Variante B: Wert 4 wird mit dem neuen Wert überschrieben, der Rest bleibt.
Wenn die Option deaktiviert ist: Neue Werte überschreiben bestehende Werte; Leerwerte (null, Leerstring) überschreiben/entfernen bestehende Werte.
in Variante A: Der neue Wert ist als einziger vorhanden. 1. und 2. Wert wurden geleert und sind somit frei. Der neue Wert rückt an den ersten freien Platz
in Variante B: Das Attribut hat nun 2 Werte: der neue Wert auf Position 1 und der Wert von Position 5 ist nun an Position 2 (aufgerückt).
Das Verhalten zu frei gewordenen Positionen gilt nur, wenn das Attribut keine Sub-Attribute (Werte) hat. Es wird nur der Wert entfernt, nicht dessen Subs/Kinder. Am o. g. Beispiel werden z. B. der Position 2 noch Werte für dessen Sub-Attribute gegeben.
Da Position 1 seinen Wert verliert und keine Subs besitzt, ist diese Position frei. Damit rücken die Subs der Position 2 zur 1 auf, um Leerwerte zu vermeiden. Somit ist Position 2 frei geworden, da der Wert ebenfalls entfernt wurde (null).
Der neue Wert wird entsprechend an Position 2 gesetzt.
Bei B rückt zudem der Wert 5 noch an Position 3.
Der CSV-Import von Assets verhält sich prinzipiell gleich (jedoch werden da die Subs "leer" gesetzt). Würden im o. g. Beispiel auch für die Sub-Attribute Leerwerte gesetzt, würde man auch die "Sub- Beschränkung" umgehen bzw. auflösen:
{ "SomeAttribute": [ null, { "SomeAttribute": null, "SomeChildAttribute": [ null, null, ... ], }, null, "NewValue" ] }
Das nachfolgende Konfigurationsbeispiel legt ein neues Asset der Klasse Computer mit folgenden Parametern an:
Titel des Tickets (Typ Ticket-Job) als Notiz
ein Bild als Anhang/Attachment
ein Dynamisches Feld (Datumsfeld für Inbetriebnahme)
da die Asset-ID nicht im Eingabefeld der Macro Action gesetzt ist, muss "ClassID" und "Name" in der Version angegeben werden
"DeplStateID" ist enthalten ("Produktion")
"InciStateID" ist nicht enthalten (wird Default auf "Operational" gesetzt).
{ "ClassID": 4, "Version": { "Name": "Created by Job", "DeplStateID": 16, "Data": { "SectionGeneral": [ { "Note": "<KIX_TICKET_Title> and some text", "Attachment": [ { "ContentType": "image/jpeg", "Filename": "test.jpg", "Content": "<base64-String des Bildes> " } ] } "SectionWarranty": [ { "WarrantyExpirationDate": "2021-08-11 12:00:42", "FirstUsageDate": "<KIX_TICKET_DynamicField_PlanBegin_ObjectValue>" } ] } } }
Der angelegte Computer wird im weiteren Verlauf angepasst (Auf korrekte "AssetID" achten!).
Die "AssetID" muss im Eingabefeld der Macro Action angegeben sein, ansonsten wird ein Create versucht. Dies würde jedoch fehlschlagen, da "ClassID" fehlt (irrelevant bei Update).
Der Name des Assets wird geändert
Der Vorfallstatus wird geändert ("Störung")
"Data" -Attribute sind nicht angegeben. die bestehenden Werte bleiben daher unberührt.
{ "AssetID": 42, "Version": { "Name": "Created by Job - updated", "InciStateID": 3 } }
Der angelegte Computer wird erneut angepasst:
Es wird nur eine FQDN hinterlegt, alles andere bleibt unberührt
keine weiteren Attribute notwendig
{ "AssetID": 42, "Version": { "Data": { "SectionNetwork": [ { "FQDN": "some.test-computer.com" } ] } } }
Der angelegte Computer wird zum 3. Mal angepasst:
Es wird nur eine weitere FQDN hinterlegt, die vorherige soll erhalten bleiben.
Wert der Vorversion übernehmen ist aktiv
{ "AssetID": 42, "Version": { "Data": { "SectionNetwork": [ { "FQDN": [ null, "another.test-computer.com" ] } ] } } }
Der angelegte Computer wird zum 4. Mal angepasst:
Die 2. FQDN wird überschrieben und eine 3. FQDN wird angefügt:
Wert der Vorversion übernehmen ist aktiv
{ "AssetID": 42, "Version": { "Data": { "SectionNetwork": [ { "FQDN": [ null, "changed-another.test-computer.com", "yet-another.test-computer.com" ] } ] } } }
Der angelegte Computer wird zum 5. Mal angepasst:
Die alten FQDN werden durch eine neue ersetzt. Es gibt dann nur noch eine.
Sollte es bereits mehr als 3 FQDN geben, müsste die Liste mehr "null" Elemente enthalten. Wir wissen aber, es sind nur 3 FQDN. Also reichen 2, welche die 1. und 2. FQDN leer setzen und die 3. ersetzt. Diese wiederum rückt auch auf, da die Plätze davor frei geworden sind.
Wert der Vorversion übernehmen ist inaktiv. Somit ersetzen Leerwerte die Alt-Werte.
{ "AssetID": 42, "Version": { "Data": { "SectionNetwork": [ { "FQDN": [ null, null, "one-and-only.test-computer.com" ] } ] } } }
Die Macro Action kann nur in Jobs verwendet werden.
Ändert den Namen eines Assets, ohne eine neue Version zu generieren. Es wird die aktuelle Version des Assets aktualisiert (Name und Änderungszeitpunkt).
Wichtig
Schränken Sie die zu ändernden Assets mittels Filter ein (Schritt 3 in der Job-Konfiguration)!
Anderenfalls werden alle Assets umbenannt.
Dient bspw. dem automatischen Generieren des Asset-Namens anhand von Attributwerten, wie:
Name des Computers - bestehend aus Hersteller, User und IP-Adresse
Name eines Raumes - bestehend aus Name der übergeordneten Location und dem Raumtyp
Verwendung/Jobtyp: Asset
Parameter | Beschreibung |
---|---|
Überspringen | Ermöglicht temporäres Deaktivieren der Aktion. |
Asset Name | Der neue Name des Assets. Es können KIX-Platzhalter verwendet werden, z. B..:
Weitere Platzhalter: Assetbezogene Platzhalterbereiche |
Ersetzt die beim Import durch KIX vergeben Assetnummern durch eigene Identifikatoren.
Verwendung/Jobtyp: Asset
Parameter | Beschreibung |
---|---|
Assetnummer | Der neue Identifikator des Assets. Es können KIX-Platzhalter verwendet werden, z. B.:
|
UseCase: Assetnummern beim Import ändern
Setzt den Bearbeiter an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Bearbeiter | ID oder Login-Name des Bearbeiters. KIX Platzhalter sind möglich, z. B.: <KIX_CURRENT_UserID> Hinweis: Es findet keine Prüfung statt, ob der gewählte Agent berechtigt ist, das Ticket zu bearbeiten. |
Prüft, ob eine Bedingung wahr (true) ist und ermöglicht so den Kontrollfluss in Macros.
Das Macro wird ausgeführt, wenn die Bedingung wahr ist.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Wenn | Logischer Ausdruck der Bedingung Z. B.: Ist die Variable
Sie können Platzhalter und die in vorangehenden Macros definierten Variablen verwenden. ![]() |
Macro | Das gewählte Macro wird ausgeführt, wenn die unter "If" angegebene Bedingung wahr (true) ist. Die zur Auswahl stehenden Jobtypen entsprechen den in den Job Informationen (Konfigurationsschritt 1 im Job) Zur Auswahl stehen die gleichen Jobtypen wie in Schritt 1 der Job-Konfiguration (Job Informationen). Jedoch sind die hier als Macro gewählten Jobtypen völlig unabhängig zu Ihrer Auswahl in den Job Informationen. Abhängig von Ihrer Auswahl, stehen Ihnen weitere Aktionen und Eingabefelder zur Verfügung. |
Hinweise
Mögliche Operatoren sind u. a.:
defined
- Prüfung auf Vorhandensein (true)!defined
- Prüfung auf Nichtvorhandensein (false)&&
- Logisches UND||
- Logisches ODER
Kombinierte Operatoren wie
if-else
oderif-not
sind nicht möglich.Sie müssen in einzelne Anweisungen gesplittet werden:
Bedingung 1 = if-Anweisung
Bedingung 2 = else-Anweisung
Die Macro Action unterstützt (eingeschränkten) Perl-Code.
Das heißt, es muss ein valider Perl-Ausdruck verwendet werden, der einen booleschen Wert ergibt.
Beachten Sie bei Vergleichen:
Texte werden mit
eq
(equals) verglichenZahlen werden mit
==
verglichen
Führt Berechnungen von Formularfeldern durch, z. B.:
Berechnen der Werte von zwei Dynamischen Feldern
Ermitteln der Zielzeiten für die Wiedervorlage
Kann gut in Verbindung mit der Macro Action "Conditional" verwendet werden.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Result | Ergebnisvariable; Bezeichner der Ergebnisvariable (z. B. "CalcResult"). Die Ergebnisvariable nimmt nur das Ergebnis (Wert) der Berechnung auf. Die Ergebnisvariable kann
|
Formel | Mathematischer Ausdruck der Berechnung. Platzhalter können verwendet werden, z. B.: DF_TotalN := <DF_TotalN> + <DF_NewValueN>
![]() |
Hinweise
Wichtig
Vermeiden Sie Schleifen!
Das Ergebnis sollte nicht im Wert der Berechnung enthalten sein.
Es gilt: Punktrechnung vor Strichrechnung und möglicher Klammerung.
Erlaubte Operatoren:
Addition: +
Subtraktion: -
Multiplikation: *
ganzzahlige Division: /
Rest bei ganzzahliger Division: DIV + MOD
Die Rundung auf Nachkommastellen erfolgt durch Angabe von
scale=n
(n = Anzahl der Nachkommastellen).
Wird
scale
nicht angegeben, erfolgt eine Rundung auf die Vorkommastelle.Für die Berechnung der "Expression" wird das BC-Tool (Blue Bash Calculator) verwendet.
Infos dazu finden Sie bspw. unter:
Leere Resultate können z. B. mit dem Ausdruck
${<variablenname>}
ausgewertet werden.Beispiel zur Verwendung dieser Macro Action: Mathematische Berechnungen mit "Berechnen"
Erzeugt einen Bericht auf Basis einer bestehenden Berichtsdefinition.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Berichtsdefinition | Auf Basis der gewählten Definition werden die Parameter des Berichts als Eingabefelder eingebunden. Tragen Sie die entsprechenden Werte ein. Die Werte werden durch den Job gesetzt und der Bericht erzeugt. Die Auswahl des Ausgabeformates ist ebenfalls abhängig von der Berichtsdefinition. Der Bericht liefert ein Ergebnis, was in Folgeaktionen auch als Variable verwendet werden kann. |
Bericht | Bezeichner der Ergebnisvariable. Der Bericht liefert ein Ergebnis, was in Folgeaktionen auch als Variable verwendet werden kann. |
Hinweis: Ein Anwendungsbeispiel finden Sie unter: Berichte automatisiert erstellen
Erstellt ein Ticket, welches auf einer Ticketvorlage mit Nutzungskontext "System" basiert (Systemvorlage).
Die Macro Action liefert als Rückgabewert die IDs des erstellten Tickets und - sofern in der Vorlage definiert - die ID des erstellten Artikels.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
NewArticleID | Ergebnisvariable Individueller Name/Bezeichner einer Variable zum Speichern der Artikel ID (z. B. myArticleVariable) |
NewTicketID | Ergebnisvariable Individueller Name/Bezeichner einer Variable zum Speichern der Ticket ID (z. B. myTicketVariable) |
Template | Auswahl der Ticketvorlage, auf deren Basis die Tickets erstellt werden. Es stehen nur gültige Vorlagen mit Nutzungskontext "System" zur Auswahl. Legen Sie ggf. im Vorfeld entsprechende Ticketvorlagen an. |
Setzt einen Wert in ein Dynamisches Feld.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Überspringen | Wenn aktiviert: Überspringt die Ausführung der Aktion |
Objekt ID | Nur verfügbar in Jobs vom Typ "Ticket" ID des Objekts, an welchem das Dynamische Feld gesetzt werden soll, z. B. ID eines bestimmten Tickets oder eines bestimmten Artikels. Wichtig: Beachten Sie den Objekttyp des Dynamischen Feldes! Für Dynamische Felder mit Objekttyp "Ticket" muss die ID eines Tickets angegeben werden. Für Dynamische Felder vom Objekttyp "Artikel" muss die ID eines Artikels angegeben werden. Ist keine explizite ID angegeben, wird die ID des auslösenden Objekts verwendet ( |
Dynamic Field Name | Name des Dynamischen Feldes, z. B. "DFMobileProcessingState". |
Dynamic Field Value | Wert, der in das Dynamische Feld gesetzt werden soll, z. B. "accepted". Der zu setzende Wert ist abhängig vom Typ des Dynamischen Feldes:
|
Hinzufügen |
|
Setzt die Erfüllungszeit für ein SLA Kriterium.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
SLA Kriterium | ID oder exakter Name des SLA |
Erzwingen wenn nicht leer | Festlegung zum Überschreiben einer bereits existierenden Erfüllungszeit Mögliche Werte: 0 | 1
|
Setzt einen bestimmten Agenten in einen Artikel. Kann für die Anonymisierung verwendet werden.
Der angegebene Agent wird in den Feldern "Erstellt von" und "Geändert von" hinterlegt.
Anzugeben ist die ID oder der Login-Name des Agenten. KIX Platzhalter können verwendet werden.
Verwendung/Jobtyp: Ticket
Setzt einen bestimmten Agenten in ein Ticket.
Der angegebene Agent wird in den Feldern "Erstellt von" und "Geändert von" hinterlegt.
Anzugeben ist die ID oder der Login-Name des Agenten. KIX Platzhalter können verwendet werden.
Verwendung/Jobtyp: Ticket
Erstellt einen neuen FAQ Eintrag.
Ermöglicht aus einem Vorgang heraus FAQ Einträge zu erstellen.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
NewFAQArticleID | Ergebnisvariable Wird ein Variablenbezeichner angegeben, wird darin die ID des FAQ Artikels zur Weiterverwendung gespeichert. |
Titel | Titel des FAQ Eintrags, KIX Platzhalter sind möglich, z. B. <KIX_FIRST_SUBJECT> |
Kategorie | FAQ Kategorie, welcher der FAQ Eintrag zugeordnet wird |
Sprache | Zuordnung des FAQ Artikels einer Sprache (analog Erstellmaske für neue FAQ Artikel) |
Schlagworte | Sie können den FAQ Artikel mit Schlagworten versehen (analog Erstellmaske für neue FAQ Artikel) |
Symptom, Ursache, Lösung | Auswahlfelder Die Auswahl bestimmt, mit welchen Ticket-/Artikel-Inhalten der FAQ Eintrag befüllt wird. Artikel des ausgelösten Ereignisses: Dieser Auswahlwert funktioniert nur, wenn die Macro Action durch das Event "Artikel erstellen" oder "Artikel senden" ausgelöst wurde. Eine Verwendung in Aktionen, bei anderen Events oder in einer zeitgesteuerten Ausführung wird aktuell nicht unterstützt. ![]() |
Erstellt einen zufällig generierten String, welcher beispielsweise als Passwort für das Nutzer-Login genutzt werden kann.
Nutzen Sie im Anschluss die Macro Action Set password for user, um diesen String als Passwort für einen Nutzer zu setzen.
Parameter | Beschreibung |
---|---|
Überspringen | Wenn aktiviert: Überspringt die Ausführung der Aktion |
Länge | Länge der Zeichenkette (Zeichenanzahl) |
Dictionary | Liste der Zeichen, die zur Erzeugung der Zeichenkette verwendet werden. Falls leer, wird der Standardwert verwendet. Standard: ( 0 .. 9, 'A' .. 'Z', 'a' .. 'z' ) |
Löscht die Historie von Tickets ausgewählter Agenten bzw. nach vorangegangenen Ticketaktionen.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Aktion | Optional: Definiert, welcher History-Eintrag (basierend auf der Aktion) verändert werden soll Die Angabe regulärer Ausdrücke (RegEx) ist möglich. Der Ausdruck |
Neuer Kommentar | Optionaler Kommentar zum Historieneintrag |
Agent | Optional: ID oder Login-Name des Agenten Definiert, welcher Agent im Attribut Erstellt von des Historieneintrags gesetzt wird. Ist hier kein Agent angegeben, wird das Attribut nicht geändert. |
Aktualisiert einen bestehenden Kontakt, wenn eine KontaktID oder Kontakt-E-Mail-Adresse angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.
Legt einen neuen Kontakt an, wenn keine KontaktID angegeben ist und die Kontakt-E-Mail-Adresse unbekannt ist.
In Verbindung mit dem Zusatzmodul Connect Database ermöglicht die Macro Action die Synchronisation mit einer externen Datenbanktabelle/-view, um Kontaktdaten in KIX bereitzustellen. Agenten können so die Kontaktdaten aus einem CRM, ERP o. a. ohne doppelte Datenpflege in KIX verwenden.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
ContactID | Ergebnisvariable für den Rückgabewert. Es ist die ID des neuen bzw. zu aktualisierenden Kontakts anzugeben.
|
Kontaktobjekt (JSON) | JSON-String des Eingabeobjekts. Erlaubt sind:
Beispiel: { "Email": "maxmuster4@example.com", # oder "ContactID": 123, "Firstname": "Max", "Lastname": "Muster", "Phone": null, "PrimaryOrganisationNumber": "KNR0815", # oder "PrimaryOrganisationID": 456, "Street": "Musterstr. 123", "City": "Musterstadt", "Comment": "some comment", "Country": "Germany", "Fax": null, "Mobile": null, "Title": null, "Zip": null, "DynamicFields": [{ "Name": "Source", "Value": "created by ticket <KIX_TICKET_TicketNumber>" }] } |
Setzt den Kontakt an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Kontakt | ID, Login oder E-Mail-Adresse des zu setzenden Kontakts. KIX Platzhalter sind möglich. |
Hinweise:
Bei gleichzeitigem Setzen von Kunde und Kontakt erfolgt aktuell keine Prüfung auf
Abhängigkeit zwischen Kunde (Organisation) und Kontakt
Existenz des gesetzten Kontakts.
Mit dem Setzen eines Kontaktes wird dem Ticket dessen Primär-Organisation zugeordnet.
Das Setzen eines unbekannten Kontakts ist möglich.
Die Macro Action konvertiert Informationen eines Objekts (wie bspw. Artikel, Ticket oder Asset) entsprechend der gewählten Druckvorlage in eine PDF-Datei. Sie ist das Pendant zum Konsolen-Befehl Console::Command:: Admin::HTMLToPDF::Convert.
Sie ermöglicht
die Ausgabe von Objekt-Informationen mittels Job oder Aktion in einer PDF-Datei.
die Bereitstellung von Artikel- oder Ticket-Inhalten in automatisiert erstellten Tickets oder in E-Mails (z. B. Erstellen und Versenden von Abrechnungen oder Serviceberichten).
die Bereitstellung des erstellten PDFs an einem Dynamischen Feld vom Typ Attachment (z. B. als Artikel-Anhang).
in Verbindung mit Webhooks auch das Archivieren von Ticketvorgängen als PDF in ein Dokumentenmanagementsystem
die kombinierte Verwendung mit den Macro Actions Artikel Anhang hinzufügen und Objekt zusammenstellen.
Die Macro Action nutzt die im System hinterlegten Druckvorlagen für den PDF-Druck. In der Konfiguration der Macro Action müssen Sie angeben, welche der zur Auswahl stehenden Druckvorlagen genutzt werden soll und von welchem Objekt (basierend auf der Angabe der Druckvorlage) die Informationen für das PDF bezogen werden sollen.
Zusätzlich zu den Pflichtangaben können Sie Dateiname, Filter, Allow und Ignore angeben und so die zu druckenden Informationen beeinflussen. Hierbei werden bestimmte Informationen der gewählten Druckvorlage überschrieben, sofern diese enthalten sind. Die Vorgaben der Druckvorlage werden dabei nur temporär für die PDF-Ausgabe geändert.
Als Rückgabewert liefert die Macro Action einen Dateianhang im JSON-Format, in dem Content
, Filename
, FileSize
und ContentType
enthalten ist. Auf diesen Rückgabewert kann bspw. in der Macro Action Article Attachment Add referenziert werden, um das erzeugte PDF als Anhang an einen Artikel zu setzen.

Abb.: Verwendungsbeispiel Macro Action "Konvertieren zu PDF"
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Datei | Name der Ergebnisvariable Gibt einen Dateianhang als JSON zurück, in dem Sie können bspw. in der Macro Action "Artikel Anhang hinzufügen" auf die Variable referenzieren, um das erzeugte PDF als Anhang an einen Artikel zu setzen. |
Vorlage | Auswahl der Vorlage, welche für den PDF-Druck verwendet werden soll. Zur Auswahl stehen die im System hinterlegten Vorlagen für den PDF-Druck. |
Identifier Type | Bestimmt den internen Parameter des Objekts (Objekttyp der gewählten Druckvorlage), z. B. ArticleID Definiert, von welchem Objekt die Daten bezogen werden. |
Identifikator | Wertangabe, die aufgrund des Identifikator-Typs gesetzt werden muss, damit die Daten für die Druckvorlage gewonnen werden können. Z. B.<KIX_ARTICLE_ArticleID> oder |
Dateiname | Optionaler Dateiname, der anstatt des Standardnamens verwendet werden soll Z. B.: Article_<KIX_ARTICLE_ArticleID>_<TIME_YYMMDD>. Sie können den Platzhalter <TIME_YYMMDD> verwenden, um dem Dateinamen die Erstellungszeit der PDF-Datei hinzuzufügen. |
Erweitert | Optional: Definiert, welche zusätzlichen Daten (Expands) für den Druck herangezogen werden sollen, z. B.: Dynamisches Feld. Die zur Auswahl stehenden Erweiterungen hängen von der gewählten Vorlage ab. |
Filter | Optional: Sie können Filter angeben, um bestimmte Erweiterungen einzuschränken (Format als JSON) Möglich nur bei ID-Listen. Gilt überall dort, wo das gleiche Objekt genutzt wird. Beispiel: Von einem Ticket sollen nur die für den Kunden sichtbaren Artikelberücksichtigt werden: { "Article": { "AND": [{ "Field": "CustomerVisible", "Type": "EQ", "Value": "1" }] } } |
Erlaubt (Whitelist) | Optionale Einschränkung des Tabelleninhalts. Nur möglich bei Tabellentyp "KeyValue" oder "DataSet" Überschreibt/manipuliert das, was in der Druckvorlage für die jeweilige Tabelle gespeichert ist. Die Verwendung von Regulären Ausdrücken (RegEx) ist möglich. { "InfoTableLeft": { "AccountedTime": "KEY", "DynamicField_DFChecklist": "KEY", "DynamicField_DFDropdown": "^regex$", "Created": "KEY", "CreateBy": "KEY", "ContactID": "KEY", "PendingTime": "KEY" } } Ausführliche Hinweise zum Parameter: Die Parameter Allow und Ignore |
Ignorieren (Blacklist) | Optionale Einschränkung des Tabelleninhalts. Nur möglich bei Tabellentyp "KeyValue" oder "DataSet" Überschreibt/manipuliert das, was in der Druckvorlage für die jeweilige Tabelle gespeichert ist. Der Aufbau ist analog Ausführliche Hinweise zum Parameter: Die Parameter Allow und Ignore |
Setzt den Kunden an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Organisation | ID der Organisation oder Kundennummer. KIX Platzhalter sind möglich. |
Hinweise:
Bei gleichzeitigem Setzen von Kunde und Kontakt erfolgt aktuell keine Prüfung auf
Abhängigkeit zwischen Kunde (Organisation) und Kontakt
Existenz der gesetzten Organisation
Aktualisiert eine bestehende Organisation, wenn eine OrganisationID oder Organisationsnummer angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.
Legt eine neue Organisation an, wenn keine OrganisationID angegeben ist und die Organisationsnummer unbekannt ist.
Verwendung/Jobtyp: Synchronisation
Konfigurationsparameter
Informationen zu den Parametern finden Sie auch unter: Attribute der Konfiguration
Parameter | Bedeutung |
---|---|
Überspringen | Ist hier das Häkchen gesetzt, wird die entsprechende Aktion nicht ausgeführt. Damit können Sie einzelne Aktionen von der Synchronisation (zeitweise) ausschließen, ohne den Job neu zu konfigurieren. Sind mehrere Aktionen im Job konfiguriert (z. B. zwei verschiedene LDAP-Server), laufen die anderen Aktionen normal weiter. |
Host | FQDN welches der LDAP-Server für die Synchronisation nutzt oder kommaseparierte Liste wenn mehrere Hosts angesprochen werden sollen. Beispiele:
|
BaseDN | Einstiegspunkt in die Verzeichnisstruktur. Beispiel: |
Contact / User Sync Map | JSON-String, der das Mapping von KIX-Attributen zu AD-/LDAP-Attributen beinhaltet. Das Mapping muss folgende Form haben: { "KIXAttributName" : "LDAPAttributName", "KIXAttributName" : "LDAPAttributName" } Alle im Mapping angegebenen Attribute müssen existieren. Anderenfalls kann keine korrekte Zuordnung erfolgen. Achten Sie auch auf korrekte Schreibweise. Der Kontakteintrag wird auf Basis der aus dem LDAP/AD ermittelten oder fixierten Werte erstellt bzw. aktualisiert. Die Angabe folgender Attribute ist dazu mindestens erforderlich:
AchtungAchtung!: Sind diese Angaben im LDAP-/AD-Eintrag nicht gesetzt (leer), kann kein Kontakteintrag erzeugt oder aktualisiert werden. Beispiel einer UserSync Map "ContactUserSync": { "Email": "mail", "Email1": "SET:mail@example.com", "Email3": "mail", "Email5": "automatedmail", "Title": "title", "Firstname": "givenname", "Lastname": "sn", "Street": "streetAddress", "City": "l", "Zip": "postalCode", "Phone": "telephoneNumber", "Mobile": "mobile", "Fax": "facsimileTelephoneNumber", "UserLogin": "sAMAccountName", "PrimaryOrganisationID": "SET:123", "OrganisationIDs": [ "department", "SET:13" ], "ImgThumbNail": "BINARY:jpegPhoto", "DynamicField_Source": "SET:ActiveDirectory1", "DynamicField_XYZ": "department", "DynamicField_ZIPCity":"CONCAT: postalCode}-{l}-DE" } |
UID | Name des LDAP-Attributes, welches zur eindeutigen Identifikation eines LDAP-Eintrages verwendet wird (Nutzerlogin). Zum Beispiel: Sollte kein TippDurch Setzen des Attributs "AuthAttr" im SysConfig-Schlüssel können Sie einen alternativen Kenner für das UserLogin setzen.Ist dieser bspw. auf "mail" gesetzt, kann sich ein Nutzer mit seiner im System hinterlegten Mailadresse anmelden. Werden zudem die Nutzerdaten mit dem LDAP per Job synchronisiert, kann der Nutzer sich immer mit seiner aktuellen Mailadresse anmelden, auch wenn diese sich z. B. aufgrund von Namensänderung geändert hat. Sollte die Anmeldung via Mailadresse fehlschlagen, wird die UID/das im System hinterlegte Nutzer Login als Fallback für die Authentifizierung verwendet. Bitte beachten Sie:Die Aktualisierung eines Kontaktattributs "Email" ist nur dann möglich, wenn in KIX ein Nutzereintrag vorhanden ist. Anderenfalls wird bei Änderung einer Email-Adresse im AD/LDAP ein neuer Kontakt angelegt. |
Parameter | JSON-String für LDAP-Verbindungsparameter, z. B.: Default: { "port": "389", "version": "3", "timeout": "120", "async": "0" } |
Suchnutzer DN | User DN des Nutzers mit dem sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen Beispiel: |
Suchnutzer Password | Passwort des Nutzers mit dem sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen |
Beschränkung auf GroupDN | Erlaubt die Einschränkung der abzufragenden Einträge auf Objekte, die in der angegebenen Gruppe enthalten sind. Dies kann erforderlich sein, wenn die Gruppenmitgliedschaft nicht über einen direkten Filter auf dem Kontakteintrag eingeschränkt werden kann. |
Access Attribute | Definiert das LDAP-Attribut, das zum Überprüfen der Gruppenmitgliedschaft verwendet wird. Verwendet memberUid, wenn nichts angegeben ist. Beispiel: |
User Attribute | Legt fest, ob der Distinguished Name des Benutzers ("DN") oder das im Parameter "UID" definierte LDAP-/AD-Attribut zur Überprüfung der Gruppenmitgliedschaft verwendet wird. |
Immer filtern | Permanenter LDAP Filter, der für alle Anfragen angewandt wird. Syntax: Beispiele:
Sie können auch Gruppenfilter eingetragen. Weitere Beispiele finden Sie unter: http://www.selfadsi.de/ldap-filter.htm |
Zeichensatz | Zeichensatz, in den die LDAP-Suchergebnisse konvertiert werden. Default: utf-8 |
Seitengröße | Sie können bei Bedarf die Gesamtanzahl der zu synchronisierenden Daten in mehrere Datenpakete zu je n Datensätzen aufsplitten. Bspw. wenn Sie vom Server die Nachricht erhalten, dass der Antwortdatensatz zu groß ist ("max size exceeded"). Tragen Sie hier die Anzahl der Datensätze ein, die pro Anfrage (Request) übertragen werden. Die Verarbeitung erfolgt dann blockweise in Paketen mit bspw. 20 Datensätzen. |
Debug | Debug-Ausgaben de-/aktivieren. Mögliche Werte: Ist der Parameter aktiv, werden wesentliche Schritte des LDAP-/AD-Datenabgleichs im Log des Jobs (Job-Historie) vermerkt. Hinweis
|
Dry Run | Trockenlauf (Testlauf) de-/aktivieren. Ist der Parameter aktiviert, erfolgt kein tatsächlicher Datenabgleich. Die aus der LDAP-/AD-Quelle ermittelten Daten werden jedoch im Job-Log vermerkt, als würde ein Update stattfinden. Der Datenabgleich kann somit im Vorfeld zu Testzwecken simuliert werden. HinweisDiese Option sollte wie Debug nur vorübergehend aktiviert werden, da sonst die Historieneinträge sehr umfangreich werden und entsprechend Speicherbedarf erzeugen. Es wird weiterhin empfohlen, diese Funktion in Verbindung mit AlwaysFilter zu verwenden um spezifische oder eine geringe Anzahl von LDAP-Einträgen zu prüfen. |
Anmerkung
Ist im Mapping das User-Attribut "Login" enthalten, wird auch ein User synchronisiert.
Ein vorhandener Kontakt wird beim Ausführen des Jobs, basierend auf dem Mapping, aktualisiert.
Ein nicht vorhandener Kontakt wird beim Ausführen des Jobs neu erstellt.
Hinweis
Die Nutzeranmeldung ist von der Synchronisation nicht direkt betroffen, jedoch die Funktion des "AuthSync".
Beim automatischen Import ist auf Datenbeschränkungen des AD zu achten (blockweises Einlesen).
Single-Point-of-Trust ist das externe System.
Erlaubt das Ausführen weiterer Macros innerhalb einer MacroAction.
Zur Unterscheidung:
Die Macro Action Macro ausführen kann nur an einem spezifischen Objekt ausgeführt werden.
Die Macro Action Schleife hingegen kann auf mehrere Werte/Arrays ausgeführt werden.
Verwendung/Jobtyp: Asset, Berichte. Synchronisation. Ticket
Parameter | Beschreibung |
---|---|
ObjectID | Ergebnisvariable (Optional) Die ID des Objektes, für das das Macro ausgeführt werden soll. |
Macro | Das auszuführende Makro stellt - abhängig von seinem Typ - die entsprechenden Actions zur Verfügung. Die Makros können auch von einem anderen Typ sein und sind nicht vom gewählten JobTyp abhängig. |
Ein Anwendungsbeispiel finden Sie unter Berichte automatisiert erstellen
Fügt mehrere Objekte zu einem neuen Objekt zusammen.
Kann bspw. eine aus einem Bericht extrahierte Tabelle als Artikelanhang an ein Ticket anfügen.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Objekt | Bezeichner der Ergebnisvariable. Der angegebene Bezeichner ist eine "Text-Repräsentation" des unter "Definition" deklarierten Objekts. Auf dessen Attribute und Sub-Attribute kann zugegriffen werden.
Das Objekt besitzt die Eigenschaften:
|
Hinweise:
Ein unter Definition erzeugtes Attachment-Objekt hat 3 Eigenschaften:
Filename: Name und Dateiendung des erzeugten Attachmentobjekts (z. B. "dummy.csv")
ContentType: MIME Type des Inhalts (z. B.
${Report.Results:0.ContentType}
)Infos dazu auch unter: https://wiki.selfhtml.org/wiki/MIME-Type/%C3%9Cbersicht
Content: Inhalt des Attachmentobjekts mit Angabe der Pipe
Z. B.:
${Report.Results:0.Content|JSON}
Die Angabe der Pipe mit JSON (
|JSON
) ist notwendig, um den Inhalt valide in das JSON-Format einzufügen.
Ein Anwendungsbeispiel finden Sie unter Berichte automatisiert erstellen.
Aktualisiert eine bestehende Organisation, wenn eine OrganisationID oder Organisationsnummer angegeben ist und die neuen Daten Änderungen zum aktuellen Stand darstellen.
Legt eine neue Organisation an, wenn keine OrganisationID angegeben ist und die Organisationsnummer unbekannt ist.
In Verbindung mit dem Zusatzmodul Connect Database ermöglicht die Macro Action die Synchronisation mit einer externen Datenbanktabelle/-view, um Organisationsdaten in KIX bereitzustellen. Agenten können so die Organisationsdaten aus einem CRM, ERP o. a. ohne doppelte Datenpflege in KIX verwenden.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
OrganisationID | Ergebnisvariable für den Rückgabewert / die ID der neuen bzw. zu aktualisierenden Organisation. OrgID ist höher priorisiert als Organisationsnummer. |
Organisation JSON Object | JSON-String des Eingabeobjekts. Erlaubt sind:
{ "City": "Chemnitz", "Comment": "", "Country": "Germany", "Name": "KIX Service Software GmbH", "Number": "KIX Service", # oder "OrganisationID": 23 "Street": "Schönherrstraße 8", "Url": "https://www.kixdesk.com", "Zip": "09113", "DynamicFields": [{ "Name": "Type", "Value": [ "supplier/partner (external)", "customer" ] }] } |
Setzt die Priorität an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Priorität | Exakte Bezeichnung der Priorität Sie müssen den exakten Namen des Attributs verwenden, das im Backend gespeichert werden soll. |
Erzeugt mehrstufige (verschachtelte) Aktionen.
Die Macro Action Schleife kann verwendet werden, um ein referenziertes Macro zu definieren und dieses für verschiedene Objekte auszuführen. Bspw. um den in einem Ticket dokumentierten Workaround an alle Kind-Tickets weiterzugeben oder um Änderungen an einem Eltern-Ticket auch an allen Kind-Tickets vorzunehmen (z. B. "Flächenstörung").
Zur Unterscheidung: Die Macro Action Macro ausführen kann nur auf 1 spezifisches Objekt ausgeführt werden.
Mit der Macro Action Schleife können Aktionen beliebig verschachtelt werden. Dadurch können komplexe, mehrstufige Workflows abgebildet und Verweise zwischen mehreren, aufeinander verweisende Tickets für Automatismen genutzt werden. Achten Sie jedoch darauf, keine Endlosschleifen zu erzeugen!
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Werte | Liste von Werten, die vom Loop berücksichtigt werden. Entweder kommaseparierte Liste oder durch einen Platzhalter generiertes Array (z. B. <KIX_TICKET_DynamicField_RelatedTickets_Key>). |
Schleifenvariable | Optional: Bezeichner der Ergebnisvariable für die aktuelle Loop-Wiederholung. Die Variable kann analog zu anderen Ergebnisvariablen verwendet werden. |
Maro | Konfigurationsmöglichkeit weiterer Aktionen der nächst tieferen Ebene. |
Beispiel zur Verwendung der Aktion: Verschachtelung von Macro Actions mit "Schleife"
Ermöglicht in zeit- oder eventbasierten Jobs die automatische Zuordnung von Tickets zu Agenten und entlastet somit den Dispatcher.
Mögliche Anwendungsfälle:
Beim Verschieben eines Tickets in ein Team, ordnet die Macro Action den Bearbeiter zu, welcher die wenigsten aktiven Tickets hat (und der online ist).
Periodische Prüfung aller Tickets in den Teams, die noch nicht in Bearbeitung sind und Neuvergabe der zu erledigenden Aufgaben entsprechend Auslastung und SLA-Zielen.
Der Automatismus setzt anhand der definierten Parameter den Bearbeiter sowie diverse Eigenschaften am Ticket und verschiebt sie ins entsprechende Team. Dabei wird berücksichtigt, wieviel Tickets der Agent zu bearbeiten hat, um diesen nicht zu überlasten.
Sofern Tickets nicht zugewiesen werden können, erfolgt keine Änderung des Bearbeiters. Die Tickets werden bei erneuter Jobausführung berücksichtigt.
In den Filter-Einstellungen des Jobs können Sie die Sortierreihenfolge festlegen. Damit können Sie bspw. festlegen, dass der Automatismus stets die ältesten Tickets zuerst verarbeitet und zuweist (absteigende Sortierung nach dem Alter).
Parameter | Beschreibung |
---|---|
Gesamtmenge relevante Agenten | Einschränkung der Zuteilung auf Agenten mit den hier ausgewählten Eigenschaften.
|
Online Status | Einschränkung der Zuteilung auf (nicht) aktive Agenten. Somit werden die Tickets keinen inaktiven Agenten zugewiesen (z. B. Urlaub, Krankheit usw.)
|
Berechnung Anzahl der Agententickets | Angabe der Berechnungsweise für die Ermittlung der Anzahl der aktiven Tickets eines Agenten. Bei der Ermittlung werden nur Tickets berücksichtigt, welche den hier angegebenen Ticketstatus, Teams und Tickettypen entsprechen.
|
Prozedur | Auswahl des Verteilungsverfahrens
|
Ticket-Limit (Kanban-Limit) | Maximale Anzahl an Tickets pro Agent. Definiert die maximale Anzahl an Tickets, die ein Agent in seinem Kanban-Board haben darf. Ist diese Anzahl überschritten, wird der Agent bei der Zuweisung nicht berücksichtigt. Sie können die Anzahl nach Bedarf selbst festlegen. Default: 0 (keine Limitierung) |
Setzt ein neues Passwort.
Wird initial vom Job "Password Reset Confirmed" für den Prozess zum Zurücksetzen des Nutzerpassworts verwendet.
Parameter | Beschreibung |
---|---|
Überspringen | Wenn aktiviert: Überspringt die Ausführung der Aktion |
Nutzer Login oder ID | ID des Nutzers, dessen Passwort zurückgesetzt werden soll KIX Platzhalter werden unterstützt, z. B. <KIX_TICKET_DynamicField_PwResetUserID_Value> |
Passwort | Das zu setzende Passwort Das Passwort kann zuvor mittels Macro Action "Generate Random String" erzeugt werden. Geben Sie hier die Ergebnisvariable an. Z. B. |
Wird in Ruleset-Macros verwendet, um das Macro-Ergebnis zur Weiterverarbeitung an die aufrufende Regel zu übergeben.
Liefert das Ergebnis einer zuvor ausgeführten Macro Action zurück.
Verwendung/Typ: Ticket, Asset, Synchronisation, Berichte, Kontakt
Parameter | Beschreibung |
---|---|
Result Variable | Name der Ergebnisvariable Durch Referenz auf diesen Namen kann in einer Regel auf das Macro-Ergebnis (Wert) zugegriffen werden. |
Wert | Wert, der in der Ergebnisvariable gespeichert werden soll. Diesen Wert liefert die Macro Action zurück. Sie können den Namen der Ergebnisvariable einer zuvor ausgeführten Macro Action angeben, um deren Wert zurückzuliefern (z. B.: |
Setzt ein SLA Kriterium im Ticket. Lassen Sie das Feld leer, wenn ein SLA vom Ticket entfernt werden soll.
Verwendung/Jobtyp: Ticket
Im Feld SLA ist die ID oder der Name des SLA anzugeben. Die Verwendung von KIX Platzhaltern ist möglich.
Die Macro Action veranlasst das Pausieren oder Fortsetzen der Reaktions- bzw. Lösungszeit am Ticket anhand des am Ticket gesetzten Status. Sie wird vom initialen Job "SLA Time Suspension" verwendet.
Erhält ein Ticket einen Status, der im zugeordneten SLA als Auszusetzende Ticketstatus für Reaktions- und/oder Lösungsdauer hinterlegt ist, wird das entsprechende SLA Kriterium pausiert. Verlässt das Ticket diesen Status wieder, läuft die Zeit für das entsprechende Kriterium weiter.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
SLA Kriterium | Exakter Name des zu pausierenden/fortzusetzenden SLA Kriteriums (FirstResponse oder Solution)
|
Setzt den Sperrstatus eines Tickets.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Sperren | Exakte Bezeichnung des Sperrstatus, z. B. "lock" oder “unlock” |
Setzt den Status am Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Status | Wählen Sie den zu setzenden Status aus. z. B. neu | offen | warten zu Erinnerung |
Hinweise:
Bei Setzen eines Warten-Status (Statustypen "pending reminder" oder "pending auto") sind weitere Parameter möglich. Zudem muss mindestens eine Angabe zur Wartezeit definiert werden:
Warten" - Zeitdifferenz: Differenz des zu setzenden Zeitpunktes zum Ausführungszeitpunkt bzw. relative Wartezeit in Sekunden. Eine Angabe in Form "60 * 60 * 24" ist möglich. Nicht zulässige Werte, werden als "0" interpretiert.
Warte Zeitpunkt: Zielzeitpunkt in Format "YYYY-MM-DD hh:mm:ss". Es können auch Platzhalter verwendet werden, um Zielzeitpunkte bspw. aus dynamischen Feldern des Typs Date oder DateTime zu beziehen (z. B. KIX_TICKET_DynamicField_DatumZeit).
Zielzeit: kann den Wert EOB
, BOB
oder <leer>
annehmen.
BOB
setzt den "Begin Of Businessday" des durch PendingDiffTime oder PendingDateTime avisiert Zielzeitpunkts.Liegt der Zielzeitpunkt außerhalb der Servicezeit wird der nächste Servicetag betrachtet.
EOB
setzt den "End Of Businessday".Wird keine der Optionen genutzt, wird der exakte Zeitpunkt eingetragen.
PendingTimeOffset hat Vorrang gegenüber PendingDateTime.
Wird bei PendingTimeOffset oder PendingDateTime eine Zeit angegeben und zusätzlich EOB oder BOB, hat die Eingabe bei Target Time Vorrang.
Setzt das Team an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Team | Vollständige Bezeichnung des zu setzenden Teams. KIX Platzhalter sind möglich. Um untergeordnete Teams zu setzen, gilt folgende Schreibweise: Ebene1::Ebene2::Ebene3 Beispiel: 2nd-Level::On Site::Chemnitz
|
Extrahiert Teile aus einem bestehenden Text.
Die Macro Action Kann bspw. die in einem Bericht erzeugte Ergebnistabelle (oder Teile davon) extrahieren, um sie im Nachrichtentext oder im Artikelanhang bereitzustellen.
Verwendung/Jobtyp: Asset, Berichte. Synchronisation. Ticket
Parameter | Beschreibung |
---|---|
ExtractedText | Ergebnisvariable Individueller Bezeichner der Ergebnisvariable, welche den extrahierten Text aufnimmt. |
RegEx | Gültiger Regulärer Ausdruck z. B. |
Text | Der Text, auf dem die RegEx angewendet werden soll. Sie können Variablen und Platzhalter verwenden, z. B. |
Capture Group Names | Optionale Benennung der einzelnen Capture Groups des RegEx. Sind keine Namen angegeben, werden die Gruppen per Index durchnummeriert (1,..., n) |
Bei Verwendung als Variable in anderen Actions:
Wird kein Variablenname vergeben, so lautet dieser:
ExtractedText
Zugriff auf Werte der Variable erfolgt mittels Angabe der Capture Group, z. B.:
keine Variable definiert und auch keine benannte Capture Group:
${ExtratcedText.1}
benannte Variable und benannte Capture Group:
${MyVariable.MyValue}
Ein Anwendungsbeispiel finden Sie unter Berichte automatisiert erstellen
Legt ein neues Ticket mit vordefinierten Werten an.
Verwendung/Jobtyp: Ticket
Die anzugebenden Parameter sind analog zur Ticketerstellmaske. Zusätzlich können Ergebnisvariablen und Dynamische Felder inkl. ihrer Werte verwendet werden.
Parameter | Beschreibung |
---|---|
Ergebnisbezeichnungen | Ermöglicht die Speicherung der Ticket ID in einer Variablen, um bspw. in nachfolgenden Macro Actions darauf zu referenzieren (s. Variablen)
|
Anhangsobjekt 1 bis 5 | Optional: Angabe eines Anhang-Objektes mit den Attributen Es ist der Bezeichner der Ergebnisvariable anzugeben. Z. B.: Anhang-Objekte können mit der Macro Action Objekt zusammenstellen oder Konvertieren zu PDFerstellt werden. Anwendungsbeispiel: Berichte automatisiert erstellen |
Article Dynamic Fields | Setzen von Dynamischen Feldern am Artikel
|
Ticket Dynamic Fields | Setzen von Dynamischen Feldern am Ticket
|
Hinweise:
Falls nichts gesetzt wird, gelten folgende Standardwerte:
Sperrstatus: "unlock"
Bearbeiter: der aktuelle Nutzer wird gesetzt
Verantwortlicher: root (ID: 1)
Kunde:
wenn Kontakt gefunden: dessen Organisation
kein Kontakt gefunden: Kontakt als unbekannter Kontakt
Type: Wert aus SysConfig-Schlüssel "Ticket::Type::Default"
Soll in den Artikeltext ein mehrzeiliger Text (DF Typ "TextArea") via KIX-Platzhalter eingefügt werden, so müssen Sie das Suffix
_HTML
verwenden, um Zeilenumbrüche zu erhalten.Beispiel: <KIX_TICKET_DynamicField_WorkOrder_HTML>
Konfigurieren Sie Benachrichtigungen so, dass kein neuer Artikel anlegt wird. Sonst erscheint diese Benachrichtigung als erster Artikel.
Löscht Tickets.
Achtung
Die Aktion kann nicht rückgängig gemacht werden!
Es ist nicht möglich, spezifische Tickets zu löschen, da die Ticketnummer nicht als Filterkriterium zur Verfügung steht.
Diese Aktion beendet den Job. Nachfolgende, ticketbezogene Aktionen werden nicht ausgeführt (außer Ticket erstellen).
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
keine | - |
Fasst 2 Tickets zusammen, bspw. um eine fehlgeleitete E-Mail (Quelle) an ein Ticket (Ziel) anzuhängen.
Wird auch vom initial ausgelieferten Job "TicketMerge" in Verbindung mit der Ticketaktion "Zusammenfassen" verwendet.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Zielticket | Die Ticketnummer des Zieltickets oder der Name des dynamischen Feldes, welche die ID des Zieltickets enthält. |
Ticketattribut | Kommaseparierte Liste von Ticketattributen. Die Liste enthält die Attribute des Ausgangstickets, welche ans Zielticket geschrieben werden. Übersetzungen der Attributs-Namen sind nicht möglich. |
Dynamische Felder | Kommaseparierte Liste der Namen der dynamischen Felder, die ans Zielticket übernommen werden. Übersetzungen der Namen sind nicht möglich. |
Werte für Dynamische Felder erzeugen |
|
Setzt den Titel an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Titel | Der Text des zu setzenden Titels. KIX Platzhalter sind möglich. Es können jedoch keine Platzhalter für Dynamische Felder der Typen "Checklist" und "Dropdown" verwendet werden. |
Setzt den Tickettyp an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Typ | Exakte Bezeichnung des zu setzenden Typs, z. B. "Vorfall". |
Deklariert eine Variable zur flexiblen Verwendung in nachfolgenden Actions.
Verwendung/Jobtyp: Asset, Berichte, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
Variable | Individueller Bezeichner der Variable Die Variable dient als Ergebnisvariable. Sie kann folgende Werte aufnehmen:
|
Wert | Wert mit dem die Variable vordefiniert sein soll oder Variablenbezeichner/Platzhalter für den zu setzenden Wert. |
Setzt den Verantwortlichen an einem Ticket.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Verantwortlicher | ID oder Login-Name des Verantwortlichen KIX Platzhalter sind möglich Es findet keine Prüfung statt, ob der gewählte Agent berechtigt ist, das Ticket zu bearbeiten. |
Setzt den Vorfallstatus an Assets.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
Asset | Nummer des Assets, dessen Vorfallstatus geändert werden soll. Mehrere Assets können durch Komma getrennt angegeben werden. KIX Platzhalter sind möglich. |
AssetID | Nummer des Assets, dessen Vorfallstatus geändert werden soll. Mehrere Assets können durch Komma getrennt angegeben werden. KIX Platzhalter sind möglich. |
Vorfallstatus | Name des zu setzenden Vorfallstatus, z. B. Incident Anzugeben ist der exakte Name, so wie er im General Catalog definiert ist. Übersetzungen sind nicht möglich. |
Pausiert die Ausführung des Jobs für die angegebene Zeit.
Kann bspw. verwendet werden, wenn der Request für ein Webhook oder WebhookExtended eine längere Zeit zum Verarbeiten benötigt und erst nach einer Wartezeit ein weiterer Request gesendet wird.
Verwendung/Jobtyp: Asset, Kontakt, Report, Synchronisation, Ticket
Geben Sie im Parameter Warten|Wait
an, wie lange die Ausführung des Jobs pausieren soll (Angaben in Sekunden).
Der Job wartet die angegebene Anzahl an Sekunden, bevor er mit der Ausführung der nachfolgenden Macro Actions fortfährt.
Kommunikation mit anderen Systemen. Sendet eine vordefinierte Ereignismeldung an ein externes System (ERP, Server etc.)
Zum Beispiel: Senden der Ticketnummer und der Summe der gebuchten Aufwände an ein ERP-System.
Verwendung/Jobtyp: Ticket
Parameter | Beschreibung |
---|---|
URL | Zeichenkette (Endpunkt-URL für einen APIAufruf) |
Methode | Übertragungsmetode (Protokoll) Es wird ein asynchroner GET/POST-Request gesendet.
|
Header | Request Header Die angegebenen Werte werden als HTTP-Header verwendet. Pro Zeile ist 1 Header als Key-Value-Paar anzugeben. |
Daten | Request Data Daten, die der Request übertragen soll. Pro Zeile ist ein Key-Value-Paar anzugeben. Es können Platzhalter verwendet werden. ![]() |
Hinweise
Steht für Ticket- und Artikel-Aktionen zur Verfügung.
Es werden die grundlegenden SysConfig- Einstellungen (Proxy, Timeout, etc.) von WebUserAgent als Grundlage genommen.
Es findet keine Ergebnisverarbeitung statt ("fire & forget").
Es können keine Strukturen und Wert-Mappings definiert werden.
Es können keine Anhänge versendet werden.
Veränderung an KIX-Objekten sind nicht möglich.
Der Response-Status wird in der Tickethistorie dokumentiert ("Webhook called - response xxx received")
Wiederholt die Ausführung des Macros solange eine konfigurierte Bedingung erfüllt ist.
Zum Beispiel: Ein Webhook-Request liefert, dass weitere Daten abgerufen werden können (Paging bei APIs). Der Job soll weitere Requests auslösen, bis alle Daten abgerufen und verarbeitet wurden.
Verwendung/Jobtyp: Asset, Kontakt, Report, Synchronisation, Ticket
Parameter | Beschreibung |
---|---|
While | Geben Sie die Bedingung an, die erfüllt sein muss, damit die unter "Macro" angegebene Macro Action ausgeführt wird. Die Macro Action wird solange ausgeführt, wie die hier angegebene Bedingung zutrifft |
Macro | Konfigurieren Sie hier die Macro Action, die ausgeführt werden soll. Wählen Sie den Objekttyp und die auszuführenden Aktionen und konfigurieren Sie diese nach Bedarf |
Maximale Ausführung | Zur Vermeidung von Dauerschleifen können Sie die maximale Anzahl an Durchläufen angeben. Ist keine Anzahl angegeben, wird nach 1000 Durchläufen abgebrochen. |
Setzt einen Wert als Zeitbuchung in ein Ticket.
Verwendung/Jobtyp: Ticket
Folgende Angaben sind im Parameter Zeit buchen
möglich:
Zeit in Minuten
oder:
KIX-Platzhalter
z. B.: <KIX_TICKET_DynamicField_someDynamicFieldName>
Durch Angabe eines Platzhalters können Sie bspw. den in einem Dynamischen Feld gesetzten Wert als Zeitbuchung setzen.
oder:
Bezeichner einer Ergebnisvariable
z. B.:
${ErgebnisDerBerechnung}
Durch Angabe einer Ergebnisvariable kann der Wert einer zuvor durchgeführten Berechnung als Zeitbuchung gesetzt werden.
