Hauptkomponenten

MesoWorkerService besteht aus vier Hauptkomponenten, die jeweils spezifische Aufgaben automatisch ausführen. Jede Komponente läuft als geplanter Job mit konfigurierbaren Zeitplänen.

Mail-Dienst

Funktion: Automatischer E-Mail-Versand basierend auf Workflow-Ereignissen in WinLine

Ausführung: Alle 30 Sekunden (konfigurierbar über Quartz__MailWorkerJob__scheduler)

Funktionsweise:

Der Mail-Dienst überwacht kontinuierlich WinLine-Workflows und versendet automatisch E-Mails, wenn bestimmte Kriterien erfüllt sind.

Workflow-Prüfung
- Der Dienst ruft Workflows aus WinLine ab, die den konfigurierten Filterkriterien entsprechen
- Filter können zeitbasiert sein (z.B. nur Workflows der letzten 24 Stunden)
- Zusätzliche Filterkriterien ermöglichen detaillierte Selektion
Empfänger-Ermittlung
- Das System ermittelt automatisch die richtigen Empfänger basierend auf hierarchischen Regeln
- Unterstützt Kunden, Ansprechpartner, Vertriebsmitarbeiter und statische Empfänger
- Fallback-Mechanismen sorgen dafür, dass immer ein Empfänger gefunden wird
E-Mail-Erstellung
- Mail-Texte werden aus Vorlagen generiert
- Platzhalter werden automatisch durch echte Workflow-Daten ersetzt
- Anhänge werden aus Workflows und Belegen zusammengestellt
Versand und Protokollierung
- E-Mails werden über konfigurierte SMTP-Konten versendet
- Jeder Versand wird im Mail-Journal protokolliert
- Bei Fehlern werden Administratoren benachrichtigt

Konfiguration:

Mail-Einstellungen werden pro Mandant in der Administrationsoberfläche konfiguriert. Details zur Konfiguration finden Sie im Abschnitt Mail-Dienst Konfiguration.

Screenshots:

SMTP Konto SMTP-Konto Einstellungen

E-Mail Einstellungen E-Mail-Einstellungen für einen Workflow

Mail-Template Mail-Vorlage mit Platzhaltern

Workflow-Erzeugung aus Bestelldateizeilen

Funktion: Automatische Erstellung von CRM-Fällen aus Bestelldateizeilen

Ausführung: Alle 5 Minuten (konfigurierbar über Quartz__OrderLineWorkerJob__scheduler)

Funktionsweise:

Dieser Dienst ermöglicht es, aus Bestelldateizeilen in WinLine automatisch CRM-Fälle zu erzeugen. Dies ist besonders nützlich für wiederkehrende Serviceaufträge oder projektbasierte Tätigkeiten.

Beleg-Überwachung
- Der Dienst überwacht Bestelldateizeilen (z.B. Auftragspositionen)
- Filterkriterien bestimmen, welche Zeilen verarbeitet werden
- Unterstützt verschiedene Belegarten (Angebote, Aufträge, Lieferscheine, Rechnungen)
Duplikats-Prüfung
- Jede Zeile wird über Kontonummer, Laufnummer und Zeilennummer identifiziert
- Bereits verarbeitete Zeilen werden übersprungen
- Protokollierung verhindert Mehrfachverarbeitung
Workflow-Erstellung
- Für jede relevante Zeile wird automatisch ein CRM-Fall erstellt
- Workflow-Felder werden aus Belegdaten befüllt (Kurzbeschreibung, Langbeschreibung, Datumsfelder)
- Template-basierte Textgenerierung mit Platzhaltern
Optionale Fall-ID-Speicherung
- Die erzeugte Fall-ID kann in eine benutzerdefinierte Spalte der Belegzeile geschrieben werden
- Ermöglicht Rückverfolgung von Beleg zu CRM-Fall
Verknüpfung mit Beleg-Workflow
- Beleg-Workflow als Elternfall verknüpfen: Verknüpft die erzeugten Belegzeilen-Workflows mit dem übergeordneten Beleg-Workflow als Tochter-Fälle
- Warte auf Beleg-Workflow (NEU): Verhindert die Erzeugung von Belegzeilen-Workflows, bis ein Beleg-Workflow existiert
  - Wenn aktiviert, werden Belegzeilen nur verarbeitet, wenn bereits ein Workflow für den Beleg (Angebot, Auftrag, Lieferschein oder Rechnung) vorhanden ist
  - Nicht verarbeitete Zeilen werden beim nächsten Job-Lauf erneut geprüft
  - Nützlich für sequentielle Workflow-Erzeugung: erst Beleg-Workflow, dann Zeilen-Workflows
Anhänge anfügen
- Beleg-Dokument anfügen: Fügt das Beleg-PDF aus der ArchivId der Belegstufe an (z.B. ArchivIdAngebot, ArchivIdAuftrag, ArchivIdLieferschein, ArchivIdFaktura)
- Beleg-Anhänge anfügen: Fügt alle Beleganhänge aus der DokumentenId des Belegs als Anhänge zum CRM-Fall hinzu
- Übergeordnete Fall-Anhänge: Kopiert Anhänge vom übergeordneten CRM-Fall, wenn LinkVoucherWorkflowAsParent aktiviert ist
- Alle Anhänge werden automatisch als CrmUploads-Einträge gespeichert
- Duplikate werden erkannt und übersprungen

Datumsfeldkonfiguration:

Der Dienst unterstützt zwei Datumsvarianten:

Standard: Lieferdatum und bestätigtes Lieferdatum
Kalender: Kalender-Startdatum und Kalender-Enddatum

Das Enddatum kann über verschiedene Modi berechnet werden:

Bestätigtes Lieferdatum
Lieferdatum
Lieferdatum plus Zeitversatz
Lieferdatum plus Stunden aus Menge
NULL (kein Enddatum)

Platzhalter in Vorlagen:

Vorlagen unterstützen Platzhalter für Belegdaten. Eine vollständige Übersicht aller verfügbaren Eigenschaften finden Sie in der BestelldateiMitte-Klassendokumentation.

Zeilenebene:

{Artikelnummer}, {Bezeichnung}, {Menge}, {Einzelpreis}, {Gesamtwert}
{Lieferdatum}, {BestaetigtesLieferdatum}
{Projektnummer}, {Vertreternummer}, {Kostenstelle}

Belegebene:

{BestelldateiKopf.Auftragsnummer}, {BestelldateiKopf.Belegnummer}
{BestelldateiKopf.Belegart}, {BestelldateiKopf.Datum}
{BestelldateiKopf.Konto.Name}, {BestelldateiKopf.Konto.Adresse.Ort}

Formatierung:

{Lieferdatum:dd.MM.yyyy} - Datum formatiert
{Einzelpreis:C2} - Währung mit 2 Dezimalstellen
{Menge:N0} - Zahl ohne Dezimalstellen

Hinweis: Für eine vollständige Übersicht aller verfügbaren Formatierungsoptionen (RTF-Konvertierung, Prefix/Suffix, etc.) siehe Formatangaben für Platzhalter.

Beispiel Kurzbeschreibung:

{BestelldateiKopf.Auftragsnummer}: {Artikelnummer} {Bezeichnung}

Ergebnis: AUF-12345: ART001 Premium-Widget

Konfiguration:

Workflow-Erzeugungseinstellungen werden pro Mandant in der Administrationsoberfläche konfiguriert. Für Details zu Platzhaltern und Formatierung siehe Formatangaben für Platzhalter.

Anhangsverwaltung:

Die folgenden Optionen stehen zur Verfügung, um Dokumente automatisch an die erzeugten CRM-Fälle anzufügen:

Beleg-Dokument anfügen (AttachVoucherDocument)
- Fügt das Hauptdokument des Belegs aus der ArchivId der entsprechenden Belegstufe an
- Unterstützt alle Belegarten: Angebot (ArchivIdAngebot), Auftrag (ArchivIdAuftrag), Lieferschein (ArchivIdLieferschein), Rechnung (ArchivIdFaktura)
- Das Dokument wird als PDF aus dem Archiv geladen
Beleg-Anhänge anfügen (AttachVoucherAttachments)
- Fügt alle zusätzlichen Anhänge des Belegs aus der DokumentenId an
- Lädt alle zum Beleg gehörenden Dokumente über ArchivBusiness.LadeBelegDokumenteAsync
- Besonders nützlich für zusätzliche Unterlagen wie Lieferscheine, Zertifikate, etc.
Übergeordnete Fall-Anhänge anfügen (AttachParentWorkflowAttachments)
- Kopiert alle Anhänge vom übergeordneten CRM-Fall
- Funktioniert nur in Verbindung mit "LinkVoucherWorkflowAsParent"
- Ermöglicht die Vererbung von Dokumenten entlang der Belegkette (Angebot → Auftrag → Lieferschein → Rechnung)

Wichtige Hinweise zur Anhangsverwaltung:

Alle Anhänge werden als CrmUploads-Einträge im CRM-System gespeichert
Duplikate werden automatisch erkannt und nicht erneut angehängt
Die Dokumentenkonvertierung (SPL → PDF) erfolgt automatisch über den MesospoolService
Bei Fehlern werden detaillierte Log-Einträge erstellt, ohne die Workflow-Erstellung zu unterbrechen

Terminsynchronisation

Funktion: Automatische Erstellung von Kalender-Terminen aus CRM-Einträgen über MS Graph API

Ausführung: Alle 10 Minuten (konfigurierbar über Quartz__AppointmentWorkerJob__scheduler)

Funktionsweise:

Dieser Dienst ermöglicht es, aus CRM-Einträgen (Workflows) in WinLine automatisch Termine in Microsoft Exchange/Outlook-Kalendern zu erstellen. Die Termine werden über die Microsoft Graph API direkt in den persönlichen Kalendern der Empfänger angelegt.

CRM-Einträge-Auswahl
- Der Dienst überwacht konfigurierte Workflows
- Flexible Filterkriterien für präzise CRM-Eintrags-Selektion
- Nur noch nicht verarbeitete Einträge werden berücksichtigt
Datumsfeld-Ermittlung
- Wählbare Datumsfelder aus CRM:
  - Start-/Enddatum (C006/C007)
  - Kalenderstart-/-enddatum (C031/C032)
  - Eskalationsdatum (C018)
  - Erfassungsdatum (C005)
- Optional: Zeitdauer-Addition zu ermittelten Datumsfeldern
- Ganztags-Option steuerbar über konfigurierbare CRM-Eigenschaft
Empfänger-Ermittlung
- Flexible Kombination mehrerer Empfänger-Quellen:
  - Verfassender Benutzer: Ersteller des Workflows
  - Delegiert an Benutzer: Zuständiger Benutzer
  - Delegiert an Gruppe: Alle Mitglieder der zugewiesenen Gruppe
  - XRM-Einträge: Alle unterstützten Typen aus CrmMehrfacheinträgen
  - XRM-Einträge (Benutzer): Nur Benutzer (Typeeigenschaft = 99)
  - XRM-Einträge (Gruppe): Nur Gruppen (Typeeigenschaft = 101)
  - XRM-Einträge (Konto): Nur Konten (Typeeigenschaft = 1)
  - XRM-Einträge (Kontakt): Nur Kontakte (Typeeigenschaft = 6)
  - XRM-Einträge (Vertreter): Nur Vertreter (Typeeigenschaft = 51)
  - Vertreter: Vertreter des zuständigen Benutzers (Incidence.Vertreter)
  - Kunde: Kundenkonto (Incidence.Kundenkonto)
  - Händler: Händlerkonto (Incidence.Haendlerkonto)
  - Kontakt Kunde: Kundenkontakt (Incidence.KontaktKunde)
  - Kontakt Händler: Händlerkontakt (Incidence.KontaktHaendler)
- Duplikate werden automatisch entfernt
Termin-Inhalt
- Betreff und Body mit VariableReplacementService
- Unterstützt Platzhalter wie {{Fall.Kurzbeschreibung}}, {{Fall.Beschreibung}}
- Vollständige Formatierungsmöglichkeiten verfügbar (siehe Formatangaben für Platzhalter)
- HTML-Formatierung für Body möglich
- Optional: Fall-Anhänge mit Filterung nach Archiv-Formular-ID
Termin-Erstellung
- Termine werden über MS Graph API in persönlichen Kalendern erstellt
- Pro Empfänger ein separater Termin
- Authentifizierung über Azure AD Client Credentials (App-only)
- Journal-Protokollierung mit Graph Event ID für Nachverfolgung
Rücksynchronisation (Optional)
- Änderungen an Terminen in Exchange können zurück in CRM synchronisiert werden
- Nur verfügbar wenn CRM-Eintrag zu einem einzelnen Termin führte
- Konfigurierbar mit Zeithorizont (z.B. 7 Tage)
- Synchronisiert Änderungen an:
  - Datum (Start/Ende) → entsprechende CRM-Datumsfelder
  - Betreff → Kurzbeschreibung
  - Body → Beschreibung
Folgeschritte-Unterstützung
- CRM-Workflows können aus mehreren Schritten bestehen (Id > 0 mit verschiedenen Schrittnummern)
- Bereits erstellte Termine für einen Fall werden unabhängig von der Schrittnummer erkannt
- Bei Folgeschritten werden bestehende Termine automatisch erkannt:
  - Gleicher Empfänger: Termin wird aktualisiert (bei aktivierter Änderungserkennung)
  - Neuer Empfänger: Neuer Termin wird erstellt
- Journal-Einträge verweisen auf die aktuelle Schrittnummer
- Ermöglicht das Verschieben von Terminen über nachfolgende Workflow-Schritte
Änderungserkennung (Optional)
- Aktivierbar über EnableChangeDetection in den AppointmentSettings
- Prüft ob sich termin-relevante Felder geändert haben:
  - Datum (Start/Ende)
  - Betreff
  - Body
  - Empfänger
- Aktualisiert bestehende Termine bei Änderungen
- Erstellt neue Termine für neu hinzugekommene Empfänger
- Verhindert Duplikate bei unveränderter Daten
Automatisches Löschen von Terminen (Optional)
- Termine können automatisch verhindert oder gelöscht werden, wenn bestimmte Bedingungen erfüllt sind
- Zwei Löschbedingungen stehen zur Verfügung (einzeln oder kombiniert):
  - DeleteProperty: Eigenschaft die angibt, dass der Termin nicht erstellt werden soll
  - DeleteFilter: Filterkriterium zur Ermittlung welche Termine nicht erstellt werden sollen
- Prävention vor Erstellung: Löschbedingungen werden VOR der Terminerstellung geprüft - Termine die Bedingungen erfüllen werden gar nicht erst angelegt (Performance-Optimierung)
- Nachträgliche Löschung: Bereits erstellte Termine werden gelöscht wenn:
  - Löschbedingungen nachträglich konfiguriert wurden
  - CRM-Daten nach Terminerstellung geändert wurden (z.B. Eigenschaft nachträglich gesetzt)
- Löschung erfolgt pro Empfänger einzeln über die Graph API
- Journal-Protokollierung mit Deleted und DeletedOn für Nachverfolgung

Voraussetzungen:

Für die Graph API Integration werden folgende Voraussetzungen benötigt:

Microsoft Entra ID App Registration:
- Eine registrierte App in Microsoft Entra ID (ehemals Azure AD)
- Client ID und Tenant ID
- Client Secret zur Authentifizierung
- Konfigurierte Application Permissions:
  - Calendars.ReadWrite - Zum Erstellen/Aktualisieren von Terminen
  - User.Read.All - Zum Abrufen von Benutzer-eMail-Adressen
Admin Consent:
- Die konfigurierten Permissions benötigen Admin Consent
- Ein Administrator mit entsprechenden Berechtigungen muss die Zustimmung erteilen
Microsoft 365 Lizenzen:
- Benutzer benötigen Microsoft 365 / Exchange Online Postfächer
- Kalender müssen für die betroffenen Benutzer verfügbar sein

Schritt-für-Schritt-Anleitung: Microsoft Entra ID App-Registrierung erstellen

Diese Anleitung beschreibt die Erstellung einer App-Registrierung in Microsoft Entra ID für eine serverseitige Integration (App-only), welche Microsoft Graph verwendet.

Erforderliche Berechtigungen:

Entra Administrator-Rolle oder entsprechende Berechtigungen zum Erstellen von App-Registrierungen
Berechtigung zur Erteilung der Administratorzustimmung (Admin Consent)

Schritt 1: App registrieren

Öffnen Sie das Microsoft Entra Admin Center
Navigieren Sie zu: Identity → Applications → App registrations
Klicken Sie auf: New registration
Tragen Sie folgende Werte ein:
- Name: Mesonic CRM Integration
- Supported account types: Accounts in this organizational directory only (Single tenant)
- Redirect URI: Leer lassen
Klicken Sie auf: Register

Schritt 2: Wichtige IDs notieren

Öffnen Sie in der erstellten App die Seite: Overview
Notieren Sie folgende Werte für die spätere Konfiguration:
- Application (client) ID
- Directory (tenant) ID

Diese Werte werden später in den Graph API Settings im MesoWorkerService benötigt.

Schritt 3: Anmeldeinformation erstellen (Client Secret)

Navigieren Sie zu: Certificates & secrets
Unter "Client secrets" klicken Sie auf: New client secret
Konfigurieren Sie das Secret:
- Description: MesonicCRMIntegration-Secret
- Expires: Nach interner Sicherheitsvorgabe (z. B. 6 oder 12 Monate)
Klicken Sie auf: Add
Wichtig: Kopieren Sie den Wert aus der Spalte "Value" sofort in einen sicheren Passwortspeicher

⚠️ Hinweis: Der Secret-Wert wird nur einmal angezeigt und kann später nicht mehr abgerufen werden.

Schritt 4: API-Berechtigungen hinzufügen (Microsoft Graph)

Navigieren Sie zu: API permissions
Klicken Sie auf: Add a permission
Wählen Sie: Microsoft Graph
Wählen Sie: Application permissions (nicht Delegated permissions)
Fügen Sie folgende Berechtigungen hinzu:
- Calendars.ReadWrite - Ermöglicht das Erstellen und Aktualisieren von Kalenderterminen
- User.Read.All - Ermöglicht das Abrufen von Benutzerinformationen (eMail-Adressen)
Klicken Sie auf: Add permissions

Schritt 5: Administratorzustimmung erteilen (Admin Consent)

Bleiben Sie auf der Seite: API permissions
Klicken Sie auf: Grant admin consent for [Ihr Organisationsname]
Bestätigen Sie die Aktion mit: Yes
Überprüfen Sie, dass in der Spalte "Status" bei beiden Berechtigungen ein grüner Haken mit "Granted for [Organisationsname]" angezeigt wird

Schritt 6: Werte für die Konfiguration zusammenstellen

Stellen Sie sicher, dass folgende Werte dokumentiert und sicher aufbewahrt wurden:

Client ID (Application ID)
Tenant ID (Directory ID)
Client Secret (Value)

Diese Werte werden im nächsten Schritt in den Graph API Settings im MesoWorkerService hinterlegt.

Sicherheitsempfehlungen:

Bewahren Sie das Client Secret ausschließlich in sicheren Passwortspeichern oder Secrets-Management-Systemen auf (z. B. Azure Key Vault)
Dokumentieren Sie das Ablaufdatum des Secrets und implementieren Sie einen Prozess zur rechtzeitigen Erneuerung
Verwenden Sie in Produktivumgebungen idealerweise Azure Key Vault zur Speicherung der Secrets
Vermeiden Sie die Speicherung von Secrets in Quellcode, Konfigurationsdateien oder Datenbanken
Implementieren Sie eine regelmäßige Rotation der Client Secrets (empfohlen: alle 6-12 Monate)

Konfiguration:

Termin-Einstellungen werden pro Mandant in der Administrationsoberfläche konfiguriert. Für Details zu Platzhaltern und Formatierung in Subject Template und Body Template siehe Formatangaben für Platzhalter.

Graph API Settings: Erstellen Sie zunächst wiederverwendbare Graph API Zugangsdaten unter "Graph API Settings"
- Name: Bezeichnung für die Zugangsdaten (z.B. "Production Graph API")
- Client ID: Azure AD Application ID
- Tenant ID: Azure AD Directory ID
- Client Secret: Azure AD Client Secret
Appointment Settings: Konfigurieren Sie dann die Termin-Einstellungen unter "Appointment Settings"
- Graph API Settings: Wählen Sie die zuvor erstellten Graph API Zugangsdaten
- Date Field Type: Welches CRM-Datumsfeld verwendet werden soll
- Duration To Add: Optional: Zeitdauer die zum Datum addiert wird
- Recipient Sources: Kombination der Empfänger-Quellen (Mehrfachauswahl)
- Enable Back Sync: Rücksynchronisation aktivieren
- Back Sync Time Horizon: Zeithorizont für Rücksynchronisation (z.B. 7 Tage)
- Delete Property: Optional: Eigenschaft die steuert ob Termine gelöscht werden sollen
- Delete Filter: Optional: Filterkriterium zur Ermittlung zu löschender Termine

Vorteil: Die Graph API Zugangsdaten können für mehrere Termin-Einstellungen wiederverwendet werden.

Beispiel-Setup:

Graph API Settings:
  Name: "Production Graph API"
  Client ID: "12345678-1234-1234-1234-123456789012"
  Tenant ID: "87654321-4321-4321-4321-210987654321"
  Client Secret: "***************"

Appointment Settings:
  Name: "Service-Termine"
  Graph API Settings: → "Production Graph API"
  Date Field Type: CalendarStartEndDate
  Duration To Add: 01:00:00 (1 Stunde)
  Recipient Sources: DelegatedToUser + DelegatedToGroup
  Subject Template: "Service: {{Fall.Kurzbeschreibung}}"
  Body Template: "<p>Beschreibung: {{Fall.Beschreibung}}</p>"
  Enable Back Sync: true
  Back Sync Time Horizon: 7.00:00:00 (7 Tage)
  Delete Property: → "Termin löschen" (Eigenschaft 999)
  Delete Filter: → Filter für "Stornierte Aufträge"

Beispiel für Löschbedingungen:

Die Löschbedingungen werden OR-verknüpft - das heißt, wenn entweder die Eigenschaft vorhanden ist ODER der Filter zutrifft, wird der Termin gelöscht:

DeleteProperty: Eigenschaft "Termin storniert" (Nummer 150)
  → Wenn diese Eigenschaft im CRM-Fall gesetzt ist, wird der Termin gelöscht

DeleteFilter: "c017 = 101 AND c004 = -2"
  → Alle Fälle des Workflows 101 mit Status -2 (storniert) werden gelöscht

Anwendungsfälle für Terminlöschung:

Stornierte Aufträge: Automatisches Löschen von Terminen bei Auftragsstornierung
Status-Änderungen: Termine löschen wenn Fall-Status auf "abgeschlossen" oder "storniert" wechselt
Eigenschafts-basiert: Flexibles Löschen über frei definierbare CRM-Eigenschaften
Filter-basiert: Komplexe Löschbedingungen über CRM-Filterkriterien

Sicherheitshinweis:

Das Client Secret sollte sicher verwahrt werden. Verwenden Sie idealerweise:

Azure Key Vault für Production-Umgebungen
Umgebungsvariablen statt hardcoded in der Datenbank
Regelmäßige Rotation der Secrets

Überwachungsdienst

Funktion: Überwachung und Warnung bei fehlenden E-Mail-Versendungen

Ausführung: Täglich um 8:00 Uhr (konfigurierbar über Quartz__NoRuleWarningJob__scheduler)

Funktionsweise:

Der Überwachungsdienst hilft dabei, Probleme frühzeitig zu erkennen, die dazu führen, dass E-Mails nicht versendet werden, obwohl aktive Regeln vorhanden sind.

Workflow-Überwachung
- Prüft alle Workflows mit aktivierten Mail-Einstellungen
- Vergleicht CRM-Fälle mit tatsächlich versendeten E-Mails
- Berücksichtigt nur Fälle im konfigurierten Zeitraum (z.B. letzte 24 Stunden)
Grace Period
- Workflows, die jünger als die Grace Period sind, werden ignoriert
- Verhindert Fehlalarme für Workflows, die gerade verarbeitet werden
- Empfohlen: 15-20 Minuten bei 30-Sekunden-Mail-Job-Intervall
Warnungs-E-Mail
- Bei fehlenden E-Mails wird eine Warnung an Administratoren gesendet
- Enthält detaillierte Liste aller betroffenen Fälle
- Inkl. Fall-ID, Workflow-Nummer, Kurzbeschreibung und Erstellungsdatum
Duplikats-Schutz
- Versendete Warnungen werden protokolliert
- Verhindert mehrfache Warnungen für denselben Fall

Einsatzszenarien:

Fehlende Stammdaten: Kunde hat keine E-Mail-Adresse hinterlegt
Fehlkonfiguration: Mail-Einstellungen sind nicht korrekt
Restriktive Filter: Filterkriterien selektieren keine Fälle
SMTP-Probleme: SMTP-Server ist nicht erreichbar

Konfiguration:

Überwachungseinstellungen werden pro Mandant in der Administrationsoberfläche unter "No Rule Warning Settings" konfiguriert.

Wichtige Einstellungen:

LookbackPeriod: Zeitraum, wie weit zurück geprüft wird (z.B. 24 Stunden)
GracePeriod: Mindestalterzeitspanne für Workflows (empfohlen: 15-20 Minuten)
WarningRecipients: E-Mail-Adressen der Administratoren (kommagetrennt)