Skip to main content

Posteingang

Der Posteingang in KIX erfolgt automatisiert durch den regelmäßigen Abruf von E-Mail-Postfächern. Damit KIX weiß, welche Postfächer abzurufen sind, müssen Sie ein oder mehrere E-Mail-Konten in KIX einrichten.

Der Abruf kann von POP3- oder IMAP-Konten – sowohl verschlüsselt als auch unverschlüsselt - erfolgen.

Die Ersteinrichtung des Posteingangs erfolgt im ico_posteingang.png Posteingang. Weitere E-Mail-Konten können Sie im Menü Kommunikation > E-Mail > Posteingang hinzufügen und bearbeiten.

Die abgerufenen E-Mails werden in den Teams entweder als neue Tickets oder als Artikel an einem bestehenden Ticket angelegt. Wie die Verteilung erfolgen soll, können Sie für jedes E-Mail-Konto separat festlegen.

Sollen die eingehenden E-Mails auf Basis von E-Mail-Headern gezielt verteilt werden, z. B. nach bestimmten Absendern oder Schlagworten im Betreff, können Sie das über E-Mail-Filter im Menü Kommunikation > E-Mail > E-Mail Filter konfigurieren.

Wichtig

Unabhängig vom Kontotyp werden alle E-Mails vom Mailserver abgerufen und gelöscht. Wird dies nicht gewünscht, so müssen Sie die entsprechenden Einstellungen dafür direkt auf dem Mailserver vornehmen. Es gib keine Möglichkeit, E-Mails auf einem Konto zu belassen. Beachten Sie dies vor allem, wenn Sie KIX testen möchten!

Für die Einrichtung der E-Mail-Konten benötigen Sie die Anmeldeinformationen für den Posteingangsserver. Halten Sie folgende Informationen bereit:

  • Login-Name des E-Mail-Kontos

  • Passwort des E-Mail-Kontos

  • Abholstelle des E-Mail-Servers (Host:Port)

  • Abholmethode mit oder ohne Verschlüsselung (z. B. "IMAP" oder "IMAPTLS")

    bei IMAP: Verzeichnis, in dem die eingehenden E-Mails liegen (i.d.R. "INBOX")

  1. Navigieren Sie im Explorer zu Kommunikation > E-Mail > Posteingang.

    Im Contentbereich wird eine Tabelle geöffnet, welche alle im System hinterlegten E-Mail-Konten auflistet.

  2. Klicken Sie in der Tabelle auf Neues Konto.

    Es wird ein Formular-Dialog geöffnet, in dem Sie das E-Mail- Konto anlegen können.

  3. Füllen Sie das Formular aus.

  4. Wählen Sie die Art der Verteilung.

  5. Setzen Sie die Gültigkeit auf "gültig".

  6. Klicken Sie abschließend auf Speichern.

Das E-Mail-Konto ist jetzt angelegt und kann eingehende E-Mails empfangen.

Nach der Einrichtung können Sie die Korrektheit der Daten prüfen. Klicken Sie dazu auf Jetzt abrufen. Sollte der Abruf fehlschlagen, erhalten Sie eine Hinweismeldung.

Bei Bedarf können Sie die Verteilung der E-Mails unter Kommunikation > E-Mail > E‑Mail Filter unabhängig des hier eingestellten Standards weiter spezifizieren.

  1. Navigieren Sie im Explorer zu Kommunikation > E-Mail > Posteingang.

    Im Contentbereich wird eine Tabelle geöffnet, welche alle im System hinterlegten E-Mail-Konten auflistet.

  2. Klicken Sie in der Tabelle auf das zu bearbeitende E-Mail-Konto.

    Die Detailansicht wird geöffnet.

  3. Klicken Sie in der Titelzeile der geöffneten Detailansicht auf Bearbeiten.

    Es wird ein Formular-Dialog geöffnet, in dem Sie das E-Mail-Konto bearbeiten können.

  4. Nehmen Sie Ihre Änderungen am E-Mail-Konto vor.

  5. Klicken Sie abschließend auf Speichern.

Die Änderungen sind sofort wirksam.

  1. Navigieren Sie im Explorer zu Kommunikation > E-Mail > Posteingang.

    Im Contentbereich wird eine Tabelle geöffnet, welche alle im System hinterlegten E-Mail-Konten auflistet.

  2. Setzen Sie ein Häkchen vor das zu löschende E-Mail-Konto (Mehrfachauswahl möglich).

  3. Klicken Sie im Tabellenkopf auf Löschen.

    Die Schaltfläche ist nur aktiv, wenn mindestens ein Konto ausgewählt ist.

    Wenn Sie die Sicherheitsabfrage mit Ja beantworten, wird die Verbindung zum E-Mail-Konto gelöscht. Danach kann KIX keine E-Mails von diesem Konto abrufen.

KIX prüft den Inhalt eingehender E-Mails auf bekannte Informationen wie Ticketnummer und Nachrichten-ID (Message-ID). Anhand dieser Informationen ermittelt KIX, ob ein neues Ticket oder - im Falle einer Rückantwort (Follow-up) - ein Artikel an einem bestehenden Ticket anzulegen ist.

Die Suche nach einem möglichen Follow-up erfolgt über alle Teams. Existiert ein Follow-up, wird am zugehörigen, bereits existierenden Ticket ein neuer Artikel angelegt. Wird kein Follow-up erkannt, wird ein neues Ticket auf Basis der am Konto gesetzten Verteilung angelegt.

Menü

System > SysConfig

Die Überprüfung eingehender E-Mails auf mögliche Follow-ups übernehmen in KIX die nachfolgend aufgeführten Module.

Bei Bedarf können Sie die Module de-/aktivieren und somit festlegen, welche E-Mail-Inhalte geprüft werden sollen. 

  • PostMaster::CheckFollowUpModule###0100-Subject

    Sucht im Betreff der E-Mail nach einer gültigen Ticketnummer.

    Vor der Ticketnummer muss stets der konfigurierte TicketHook und der TicketHookDivider stehen.

    Standard ist: "Ticket#..."

    Muss aktiv sein, damit die, anhand einer externen Referenz bestimmte, im Betreff hinzugefügte Ticketnummer als Follow-up erkannt werden kann.

    Initial: aktiv/gültig

  • PostMaster::CheckFollowUpModule###0200-Reference

    Sucht im "Reply-To" oder References-Header nach der Message-ID, welche bspw. an einem Artikel des Systems hinterlegt ist.

    Initial: aktiv/gültig

  • PostMaster::CheckFollowUpModule###0300-Body

    Sucht im E-Mail-Text (Body) nach einer gültigen Ticketnummer.

    Initial: inaktiv/ungültig

  • PostMaster::CheckFollowUpModule###0400-Attachments

    Durchsucht den Inhalt von E-Mail-Anhängen nach einer gültigen Ticketnummer.

    Initial: inaktiv/ungültig

  • PostMaster::CheckFollowUpModule###0500-RawEmail

    Durchsucht die Rohdaten (Quelle) von E-Mails nach einer gültigen Ticketnummer.

    Initial: inaktiv/ungültig

Wie das jeweilige Modul verfahren soll, wenn ein Follow-up erkannt wurde, können Sie in den Modul-Parametern festlegen:

  • OnlyFirstMatch:

    • wenn gesetzt (1): Wurden mehrere Follow-up-Tickets erkannt, wird nur das erste Ticket verwendet.

    • wenn nicht gesetzt (0): Wurden mehrere Follow-up-Tickets erkannt, wird die E-Mail jedes erkannten Follow-ups entsprechend verarbeitet. 

  • StopAfterMatch: 

    • wenn gesetzt (1): Es erfolgt kein weiterer Aufruf nachfolgender Module, sobald ein mögliches Follow-up durch das aktuelle Modul erkannt wurde.

    • wenn nicht gesetzt (0): Es wird immer das nächste registrierte Modul aufgerufen und dessen erkannte Follow-ups der Liste hinzugefügt.

email-verteilung_pruefung-auf-follow-ups.png

Abb.: Ablaufschema der Prüfung nach möglichen Follow-ups

Konfigurationsschlüssel

PostMaster::PreFilterModule###888-ExtendedFollowUp

KIX wird standardmäßig mit aktiviertem SysConfig-Schlüssel PostMaster::PreFilterModule###888-ExtendedFollowUp ausgeliefert. Dieser Filter ermöglicht es, externe Identifikatoren (z. B. die Ticketnummer) in eingehenden E-Mails auszulesen und anhand dieser mögliche Follow-ups zuzuordnen.

Beispiel: Identifier = 'Sender_A'

Es wird eine E-Mail eingelesen, die vom Absender "info@example.de" kommt. Der Betreff ist "[SMPL::#12345] Neue Anfrage".

Der Filter erkennt am Absender, dass "Sender_A" anzuwenden ist und erkennt die externe Referenz mit der Nummer "12345" (→ ExtendedFollowUp###SenderEmail und ExtendedFollowUp###ExternalReference).

Anhand der erkannten Nummer wird im Dynamischen Feld ExternalReferenceNumber" nach einem passenden Ticket geschaut. Außerdem wird vermerkt, dass die erkannte externe Referenz im Dynamischen Feld ExternalReferenceNumber hinterlegt werden soll, egal ob ein neues Ticket erstellt wird oder ein anderer Mechanismus ein Follow-up erkennt (→ ExtendedFollowUp###DynamicFieldMapping).

Kommt eine weitere E-Mail von einem passenden Absender (z.B. von "info@example.de" oder "'support@example.de') mit dem Betreff "[SMPL::#12345] Nachfrage", so erkennt KIX die Nummer wieder und bei der Suche wird das zuvor erstellte Ticket gefunden. In diesem Fall ergänzt der Filter PostMaster::PreFilterModule###888-ExtendedFollowUp die KIX-Ticketnummer im Betreff.

Damit kann das Modul PostMaster::CheckFollowUpModule###0100-Subject das Follow-up erkennen und die E-Mail dem bestehenden Ticket zuordnen.

Sie können die externen Identifikatoren in nachfolgend aufgeführten SysConfig-Schlüsseln konfigurieren:

  • ExtendedFollowUp###Identifier

    Registriert (initialisiert) einen Bezeichner/Identifikator zur Verwendung in den nachfolgend aufgeführten SysConfig-Schlüsseln.

    Die Filterkonfigurationen werden entsprechend den hier angegebenen Schlüssel verarbeitet.

    Geben Sie ein Schlüssel-Wert-Paar an:

    • Schlüssel: Dient der alphanummerischen Sortierung der anzuwendenden Filterkonfigurationen.

    • Wert: Wird in den nachfolgend aufgeführten Konfigurationsschlüsseln als Schlüssel für die Zuordnung verwendet

    Beispiel:

    {
      "10": "Sender_A",
      "20": "Sender_B",
      "4711":
      "capeProcessCPNID"
    }
  • ExtendedFollowUp###SenderEmail

    Prüft den Absender der eingehenden E-Mail auf die angegebenen E-Mail-Domains.

    Geben Sie ein Schlüssel-Wert-Paar an:

    • Schlüssel: Muss einer der in ExtendedFollowUp###Identifier initialisierten Identifikatoren sein. 

    • Wert: E-Mail-Adresse oder Regulärer Ausdruck als Absender, der auf das "From" der eingelesenen Email zutreffen muss.

    Beispiel:

    {
      "capeProcessCPNID": ".
      +@cape-it.de|.+@kixkesk.com|.
      +@any-example.com",
      "Sender_A": ".
      +@example.de",
      "Sender_B": ".+@capeit.
      de"
    }
  • ExtendedFollowUp###ExternalReference

    Prüft den E-Mail-Betreff auf die angegebenen Regulären Ausdrücke. Erkennt somit, ob im Betreff eine der angegebenen Referenzen angegeben ist.

    Geben Sie ein Schlüssel-Wert-Paar an:

    • Schlüssel: Muss einer der in ExtendedFollowUp###Identifier initialisierten Identifikatoren sein. 

    • Wert: Muss ein Regulärer Ausdruck sein, der im Betreff die externe Referenz erfasst. Als externe Referenz wird die erste CaptureGroup des Ausdrucks verwendet.

    Beispiel:

    {
      "CapeProcessCPNID":
      "##([0-9]{6})##",
      "Sender_A": "\\[SMPL::#(.)\\]",
      "Sender_B": "\\[T#(.)]"
    }
  • ExtendedFollowUp###DynamicFieldMapping

    Prüft in den angegebenen Dynamischen Feldern nach einer bereits vermerkten Referenz und schreibt die gefundene Referenz in dieses Feld.

    Geben Sie ein Schlüssel-Wert-Paar an:

    • Schlüssel: Muss einer der in ExtendedFollowUp###Identifier initialisierten Identifikatoren sein. 

    • Wert: Der Name des Dynamischen Feldes.

    Beispiel:

    {
      "CapeProcessCPNID":"CPNID",
      "Sender_A":"ExternalReferenceNumber",
      "Sender_B":"CustomerReferenceNumber"
    }
  • ExtendedFollowUp###SortByAgeOrder

    Allgemeine Konfiguration.

    Sortiert die gefundenen Tickets nach dem Alter und steuert, ob die Zuordnung aufsteigenden (Up) oder absteigend (Down) erfolgt.

    Die externe Referenz könnte an mehreren Tickets hinterlegt werden. Durch Wahl der Sortierung können Sie festlegen, ob das Follow-up dem ältesten (Down) oder jüngsten (Up) Ticket zugeordnet wird.

    Mögliche Werte: Up | Down

  • ExtendedFollowUp###AllTicketStateTypesIncluded

    Allgemeine Konfiguration.

    Geben Sie an, welche Arten von Folgetickets berücksichtigt werden sollen.

    Mögliche Werte: 0| 1

    • 0 - First viewable tickets: Versucht die Zuordnung zuerst an Tickets, die den im SysConfig-Schlüssel Ticket::ViewableStateType angegebenen Status-Typen entsprechen. Wurde kein solches Ticket gefunden, werden auch weitere Status-Typen berücksichtigt (bspw. "geschlossen").

    • 1 - All tickets: Berücksichtigt alle Tickets ohne Einschränkung des Status-Typs.

Anmerkung

Wenn für einen Identifier "SenderEmail", "ExternalReference" oder "DynamicFieldMapping" nicht angegeben ist, erfolgt keine Verarbeitung.

Hinweis

Der Filter überschreibt keine bereits am Ticket hinterlegten Referenzen. Anhand der externen Referenz wird der Betreff um die Ticketnummer samt Hook des Tickets mit passend hinterlegter Referenz erweitert. Der SysConfig Schlüssel PostMaster::CheckFollowUpModule###0100-Subject muss daher aktiv (gültig) sein.

Die Verarbeitung der Follow-ups erfolgt in der Reihenfolge, in der sie erkannt wurden.

  1. Prüfen, ob das Follow-up-Ticket bereits einen Artikel mit der Message-ID der soeben eingelesenen Email enthält

    1. Ja: Keine weitere Verarbeitung (kein Artikel, kein Ticket, keine Header-Auswertung). Der Postmaster wertet es jedoch als: "Verarbeitung als Follow-up".

    2. Nein: Weiter mit 2.

  2. Prüfen ob Follow-up-Ticket geschlossen ist

    1. Ist das Ticket nicht geschlossen oder ist am relevanten Team die Option 'Nachfrage an Tickets' auf 'möglich' gesetzt, dann:

      1. wird ein Follow-up-Artikel erstellt

      2. die Follow-up-Header verarbeitet

      3. es greifen Automatismen zu Ticketsperre und Ticketstatus.

    2. Ist am relevanten Team die Option 'Nachfrage an Tickets' auf 'ablehnen' gesetzt, dann:

      1. wird der Artikel hinterlegt

      2. die Follow-up-Header werden nicht verarbeitet

      3. es greifen keine Automatismen.

    3. Ist am relevanten Team die Option "Nachfrage an Tickets" auf "neues Ticket" gesetzt, dann:

      1. wird die E-Mail an dieser Stelle als neues Ticket verteilt und anschließend mit dem Follow-up-Ticket verknüpft.

email-verteilung_verarbeitung-von-follow-ups.png

Abb.: Schema der Verarbeitung von Follow-ups

Menü

Kommunikation > E-Mail > Posteingang

Beim Anlegen oder Bearbeiten eines E-Mail-Kontos können Sie die Art der Verteilung auswählen. Die Art der Verteilung bestimmt, wie KIX mit den vom Konto abgerufenen E-Mails verfahren soll, wenn

  • kein Follow-up gefunden wurde

  • ein Follow-up an ein bereits geschlossenes Ticket geht und in dessen Team-Konfiguration unter Nachfrage an Tickets die Option "Neues Ticket" gesetzt ist.

Mit Ihrer Auswahl legen Sie fest, in welchem Team die E-Mails als neue Tickets erstellt werden. Sofern jedoch in einem Team die Message-ID in einem Ticket vorhanden ist, wird kein neues Ticket erstellt.

Die Verteilung können Sie für jedes E-Mail-Konto separat festlegen.

email-verteilung.png

Abb.: Auswahl der Verteilung eingehender E-Mails

Hinweis

  • Konfigurierte E-Mail-Filter übersteuern das Standard-Verhalten. Sie haben Vorrang gegenüber dem Standard.

  • Ist der E-Mail-Header 'X-KIX-Queue' mit einem gültige Team gesetzt, so erfolgt die Erstellung des Tickets im angegebenen Team und somit unabhängig der Verteilungskonfiguration. 

Parameter der Verteilung

  • Standard Team (SysConfig)

    Die vom E-Mail-Konto abgerufenen E-Mails werden in das Standard-Team verteilt. Das Standard-Team ist das Team, welches im SysConfig-Schlüssel PostmasterDefaultQueue hinterlegt ist. Im Auslieferungszustand ist dies das Team "Servicedesk". Sie können im SysConfig-Schlüssel ein anderes Team festlegen.

  • Team

    Es wird ein neues Ticket in dem Team angelegt, welches am Mailkonto hinterlegt ist.

  • Empfängeradressen (Von, Cc, etc.)

    Die vom E-Mail-Konto abgerufenen E-Mails werden anhand des E-Mail-Empfängers verteilt. Dabei gleicht KIX die Empfängerliste der abgerufenen E-Mails mit den im System angelegten E-Mail-Adressen (Systemadressen) ab (s. "Auswertung der Mailheader").

    Existiert eine der Empfänger-Adressen als Systemadresse in KIX und ist an dieser Adresse ein Team hinterlegt, so wird in diesem Team die eingehende Mail als Ticket angelegt.

    Ist an keiner relevanten Systemadresse ein Team hinterlegt, wird das neue Ticket im Postmaster-Standard-Team (Default Queue) angelegt.

    email-verteilung.png

    Abb.: Schema der Mailverteilung nach Empfängeradressen

    Die Systemadressen werden im Menü Kommunikation > E-Mail > E-Mail-Adressen angelegt und verwaltet. An jeder Systemadresse können Sie ein Team angeben. In diesem Team werden alle an die Systemadresse eingehenden E-Mails als neue Tickets angelegt, wenn im E-Mail-Konto als Verteilungsoption Empfängeradressen gewählt ist.

    Achtung

    Systemseitig wird nicht sichergestellt, dass die Zuordnung von Systemadresse und Team zu der am Team hinterlegten Systemadresse passt.

    Achtung

    Existieren mehrere Systemadressen, welche auf die gleiche Adresse verweisen, so wird für die Teamzuordnung immer der Eintrag mit der niedrigsten ID ausgewertet.

    Wir raten davon ab, mehrere Systemadressen mit gleicher E-Mail-Adresse zu verwenden!

    Auswertung der Mailheader

    KIX gleicht die Empfängerliste der abgerufenen E-Mails mit den im System angelegten E-Mail-Adressen (Systemadressen) ab. Es werden die nachfolgend aufgeführten Mailheader geprüft und die Empfänger ausgewertet.

    • Der erste Header-Empfänger, zu dem eine Systemadresse mit zugeordnetem gültigen Team gefunden wird, bestimmt das Team, in dem das Ticket erstellt wird.

    • Wurde für den Empfänger kein gültiges Team gefunden, wird der nächste Header in gleicher Weise geprüft.

    • Wurde nach allen Prüfungen kein Team gefunden, erfolgt die Ticketerstellung im Postmaster-Standard-Team (Default Queue).

    • Sind als Empfänger mehrere E-Mail-Adressen angegeben, erfolgt die Prüfung nacheinander für jede einzelne dieser E-Mail-Adressen.

    Die Mailheader werden in angegebener Reihenfolge geprüft:

    1. Resent-To

    2. Envelope-To

    3. To

    4. Cc

    5. Delivered-To

    6. X-Original-To

    Beispiel 2. Beispiel

    Im System sind die Systemadressen "projects@kixdesk.com" (ohne Teamzuordnung) und "vertrieb@kixdesk.com" (mit Team 'Vertrieb') konfiguriert. Postmaster-Standard-Team ist "Projekte".

    E-Mail an (To)

    Kopie an (Cc)

    neues Ticket im Team

    Beschreibung

    no-systemaddress@domain.com

    -

    Projekte

    Keine Systemadresse vorhanden, daher neues Ticket im Standard-Team 'Projekte'

    projects@kixdesk.com

    -

    Projekte

    Keine Teamzuordnung an Systemadresse, daher neues Ticket im Standard-Team 'Projekte'

    vertrieb@kixdesk.com

    -

    Vertrieb

    Teamzuordnung an Systemadresse vorhanden, daher neues Ticket im Team 'Vertrieb'

    no-systemaddress@domain.com

    projects@kixdesk.com

    Projekte

    Keine Systemadresse für 'To' vorhanden und für 'Cc' kein Team hinterlegt, daher neues Ticket im Standard-Team 'Projekte'

    vertrieb@kixdesk.com

    projects@kixdesk.com

    Vertrieb

    Teamzuordnung an Systemadresse ('To') vorhanden und Team an dieser Adresse hinterlegt, daher neues Ticket im Team 'Vertrieb'. Der erste Treffer gewinnt; die Prüfung des 'Cc' entfällt somit.

    projects@kixdesk.com

    vertrieb@kixdesk.com

    Vertrieb

    Keine Teamzuordnung an Systemadresse ('To') vorhanden, daher Prüfung der nächsten Adresse ('Cc'). Teamzuordnung an 'Cc' vorhanden (= erster Treffer), daher neues Ticket im Team 'Vertrieb'.