Skip to main content
Skip table of contents

Konfigurationsmöglichkeiten im Vorgangsmanagement

Systemarchitektur und Komponenten

Das Vorgangsmanagement ist tief in die CURSOR-CRM-Architektur integriert und besteht aus mehreren Kernkomponenten, die Administratoren kennen und konfigurieren können. Dazu gehören spezifische Entitäten, Skriptbibliotheken und BPM-Prozesse, die das Verhalten des Moduls steuern.

  • Entitäten: Die zentralen Entitäten sind Vorgang (Ticket) und Anliegen (Request). Diese sind mit anderen Standardentitäten wie Geschäftspartner, Ansprechpartner und Aktivität verknüpft.

  • Skriptbibliotheken: Die Hauptlogik ist in der Skriptbibliothek SC0TicketUtils gekapselt. Anpassungen und Erweiterungen der Standardlogik sollten durch Übersteuerung der Methoden in der Kundenschicht (C2) erfolgen, um die Updatefähigkeit zu gewährleisten.

  • BPM-Prozesse: Automatisierte Abläufe, insbesondere für den Versand von Benachrichtigungen, werden über dedizierte BPM-Prozesse gesteuert.

Konfiguration von Benachrichtigungen

Das System bietet granulare Einstellungsmöglichkeiten für den automatischen Versand von Benachrichtigungen. Die Steuerung erfolgt primär über globale Anwendungsvariablen und zugehörige BPM-Prozesse.

Globale Variablen

2025.6 Die folgenden globalen Variablen (zu finden unter Admin Konsole -> Globale Variablen) steuern, wann und an wen Benachrichtigungen bei Änderungen oder neuen Aktivitäten versendet werden:

Variable

Standardwert

Beschreibung

C0Ticket_Notification_DelegatedTo

false

Bei true werden Benachrichtigungen über Änderungen und neue Aktivitäten an den Benutzer im Feld "Delegiert an" gesendet.

C0Ticket_Notification_DelegatedToGroup

false

Bei true werden Benachrichtigungen über Änderungen und neue Aktivitäten an die Mitglieder der Gruppe im Feld "Delegiert an Gruppe" gesendet.

C0Ticket_Notification_Responsible

true

Bei true werden Benachrichtigungen über Änderungen und neue Aktivitäten an den Benutzer im Feld "Verantwortlich" gesendet.

BPM-Prozesse

Die Logik für den Benachrichtigungsversand wird durch die folgenden Standard-BPM-Prozesse umgesetzt:

  • C0TicketMailSending: Steuert den Versand bei Delegation an den Verantwortlichen.

  • C0TicketNotificationAfterChange: Löst den Versand von Benachrichtigungen nach einer Änderung am Vorgang oder Anliegen aus.

  • C0TicketCheckNewActivity: Prüft auf neue Aktivitäten (insbesondere bei abgeschlossenen Vorgängen) und stößt den Benachrichtigungsprozess an. Dieser Prozess kann bei Bedarf deaktiviert werden.

Zusätzlich prüft der Standard-Timer "Eskalationsdatum prüfen" minütlich, ob Fälligkeits- oder Erinnerungsdaten überschritten wurden, und versendet entsprechende Eskalationsbenachrichtigungen.

Konfiguration von Datumsfeldern

Die Vorbelegung der Datumsfelder für Fälligkeit und Erinnerung kann administrativ angepasst werden. Standardmäßig gelten folgende Werte bei der Neuanlage eines Vorgangs:

  • Fälligkeitsdatum: Aktuelles Datum + 14 Tage

  • Erinnerungsdatum: Aktuelles Datum + 7 Tage

Diese Werte werden durch die Methode getRemindDateDuration() in der Skriptbibliothek SC0TicketUtils gesteuert und können dort bei Bedarf angepasst werden.

E-Mail-Benachrichtigungen bei Vorgangsanlage

2025.5 Das System kann so konfiguriert werden, dass bei der Neuanlage eines Vorgangs automatisch eine Bestätigungs-E-Mail an den verknüpften Ansprechpartner versendet wird. Das Verhalten dieses Versands lässt sich über Methoden in der Skriptbibliothek SC0MailUtils steuern. Diese Methoden sollten in der C2-Kundenschicht übersteuert werden, um das Standardverhalten anzupassen.

  • shouldSendMailAfterTicketCreation: Eine boolesche Methode, die bestimmt, ob die E-Mail überhaupt versendet werden soll.

  • getNotificationMailTemplateName: Gibt den Namen der zu verwendenden Mailsignatur zurück. Wenn null, wird die Standardvorlage des Benutzers verwendet.

  • getNotificationMailConfigMatchCode: Definiert den MatchCode der Mail-Konfiguration. Wenn null, wird die Standardkonfiguration des Benutzers verwendet.

  • createNotificationActivitySubject: Erzeugt den Betreff der E-Mail und erlaubt eine dynamische Gestaltung, z.B. abhängig vom Vorgangstyp.

Klassifikationen und Typen

Um Vorgänge zu strukturieren und abteilungsspezifische Prozesse abzubilden, bietet das System eine mehrstufige Klassifikationsmöglichkeit. Die Konfiguration erlaubt es, die Auswahllisten für Klassifikation und Unterklassifikation abhängig vom Vorgangstyp zu filtern.

Diese Abhängigkeit wird über die Feldeigenschaften der entsprechenden Felder konfiguriert. Durch die Definition von Vorselektionen beim Validieren kann die Liste der verfügbaren Schlüssel dynamisch eingeschränkt werden. Dies ermöglicht es, dass beispielsweise verschiedene Abteilungen nur die für sie relevanten Klassifikationsmerkmale sehen und auswählen können.

Beispielkonfiguration für das Feld Klassifikation (Classification.Ticket):

  • Nachschlagesuche: LookupEntityS_KeytabKeyMappings

  • Vorselektion:

    • MasterKey.KeyMappings.EQUAL={TicketType.Ticket}

    • MasterKeyRange.KeyMappings.EQUAL=C0TICKET_TYPE

    • SlaveKeyRange.KeyMappings.EQUAL=C0TICKET_CLASSIFICATION

    • Active.KeyMappings.EQUAL=1

Skriptklasse SC0TicketUtils

Die Skriptklasse SC0TicketUtils ist das Herzstück der Vorgangsmanagement-Logik. Sie enthält Methoden für eine Vielzahl von Funktionen, von der Erstellung von Vorgangsnummern über die Steuerung von Feldvorbelegungen bis hin zur UI-Logik. Administratoren und Entwickler sollten sich mit den Methoden dieser Bibliothek vertraut machen, um Anpassungen vorzunehmen. Wichtige Änderungen und neue Methoden werden in den Release Notes dokumentiert. Für kundenindividuelle Anpassungen ist es essenziell, die Methoden in der C2-Schicht zu übersteuern, anstatt die C0-Standardbibliothek direkt zu modifizieren.

Prozesse und Automatisierungen

Neben den bereits erwähnten Benachrichtigungsprozessen gibt es weitere Standardprozesse, die administrative Beachtung erfordern:

  • 2026.2 C0AssignTicketToCurrentUser: Der Prozess hinter der Aktion "Vorgang mir zuweisen".

  • Nummerngenerierung: Die Logik zur Generierung von Vorgangs- und Anliegennummern ist in SC0TicketUtils implementiert (z.B. in generateTicketNoFromActivity und applyTicketRequestNumber) und kann dort angepasst werden, falls abweichende Nummernkonventionen erforderlich sind.

Masken- und UI-Konfiguration

Die Benutzeroberfläche des Vorgangsmanagements ist flexibel gestaltbar. Administratoren können Masken für Vorgänge und Anliegen je nach Vorgangstyp unterschiedlich konfigurieren. Dies umfasst das Ein- und Ausblenden von Feldern und ganzen Kacheln. Beispielsweise werden die spezifischen Felder für "b.better"-Kunden nur dann angezeigt, wenn der entsprechende Vorgangstyp ausgewählt ist. Die Steuerung der Sichtbarkeit erfolgt häufig über Methoden in SC0TicketUtils, wie handleTicketBbetterTabs() und handleRequestBbetterTabs().

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.