Zum Hauptinhalt springen

Notification-Architektur

Wie aus einem Event („Compliance-Schulung läuft in 30 Tagen ab") eine Notification beim richtigen Empfänger über den richtigen Channel wird.

Architektur-Übersicht

Komponenten im Detail

1. Event-Trigger

Events können entstehen durch:

  • Cron-Job (z.B. „täglich Compliance-Check")
  • System-Event (z.B. „Auftrag abgeschlossen → Prüfbericht-Versand")
  • Manuelle Aktion (z.B. Sachbearbeiter triggert „Notification an Kunde")
  • Webhook von extern (z.B. „Zahlung eingegangen → SpeamCore-Notification")

2. Subscription-Lookup

Pro Event-Typ gibt es Subscriptions:

  • User-Subscription: einzelner MA bekommt event
  • Rolle-Subscription: alle mit dieser Rolle
  • Conditional-Subscription: z.B. „nur HR-MA der Niederlassung X"
  • Cascading-Subscription: pro Event mehrere Empfänger-Gruppen

3. Channel-Auswahl

Pro Event + Empfänger:

  • In-App (immer, Notification-Center)
  • Mail (Standard-Channel für meiste Events)
  • SMS (nur kritisch — Compliance-Lücke, Notfall)
  • Push (Mobile-App, falls aktiv)
  • Webhook (an Drittanbieter)

Channel-Wahl basiert auf:

  • Event-Priorität
  • Empfänger-Präferenz (User-Settings)
  • Mandanten-Konfiguration

4. Template-Engine

Pro Event + Channel ein Template mit Variablen:

Betreff: Ihre {compliance_type}-Bescheinigung läuft am {expiry_date} ab

Hallo {user_name},

Ihre {compliance_type}-Bescheinigung läuft am {expiry_date} ab —
das ist in {days_until_expiry} Tagen. Bitte organisieren Sie zeitnah
einen Schulungs-Termin.

Mit freundlichen Grüßen,
{firm_name}

Variablen werden zur Laufzeit ersetzt. Template-Editor mit Preview.

5. Versand-Queue

Notifications landen nicht direkt im Versand sondern in eine Queue:

  • Bündelung möglich (z.B. „alle HR-Notifications einmal täglich um 18:00")
  • Rate-Limiting pro Provider
  • Retry bei Fehlern
  • Storno möglich (wenn z.B. Compliance-Lücke vorab behoben)

6. Provider-Integration

Pro Channel ein Provider (Code-verifiziert aus notificationChannel.model.ts):

Channel-TypProvider-TypenHinweis
emailsmtp (eigener Mail-Server), graph (Microsoft 365)Mail-Sync auch via Worker
smstwilioexterne Provider-API
calltwilioSprach-Anruf via API
whatsappwhatsapp_businessMeta Business API
telegramtelegram_botBot-Token-basiert
teamsteams_graphMicrosoft Graph
pushapns (iOS), fcm (Android)Mobile Push
vdsvds2465Brandmeldetechnik-Schnittstelle (VdS 2465) — Live-Connection-Status
(intern)internalIn-App-Notification ohne externe Schnittstelle

7. Versand-Log

Pro Notification:

  • Versand-Status (queued / sent / delivered / failed)
  • Bounce-Ursache bei Fehler
  • Lesebestätigung (sofern Channel das unterstützt)
  • Retry-Anzahl

Event-Typen — Übersicht

Event-TypTriggerStandard-EmpfängerChannel
compliance.expiringCron täglichMA + HR-LMail
mahnung.dueCron wöchentlichBuchh-SBIn-App
auftrag.completedSystem-EventInnendienst-VerantwortlicherIn-App
payment.receivedBanking-SyncBuchh-SBIn-App
urlaub.requestedUser-AktionHR-LMail
urlaub.approvedUser-AktionMAMail
auftrag.escalatedCron täglichTeamleiterMail + In-App
inventur.differenzInventur-AbschlussBuchh-LMail
cron.failedSystem-EventAdminMail (kritisch)

Subscription-Beispiele

Pro Rolle

„Alle MA mit Rolle Buchhaltung-SB bekommen payment.received-Events"

Conditional

„Nur Buchhaltungs-Mitarbeiter der Niederlassung Stuttgart bekommen mahnung.due für Stuttgart-Kunden"

Cascading

auftrag.escalated geht zuerst an Teamleiter — wenn nicht binnen 24h reagiert, an HR-L"

Notification-Center (In-App)

Pro Event-Typ Vorlagen-Pflicht

Bei System-Konfiguration: pro neuem Event-Typ braucht es:

  • 1+ Templates pro Channel
  • 1+ Subscriptions
  • Test-Versand mit Test-User

Best-Practices

  • Reduzieren — zu viele Notifications = werden ignoriert (Spam-Effekt)
  • Bündeln wo möglich — „1 tägliche Mail mit allen Compliance-Themen" besser als 5 einzelne
  • Channel-Mix — Standard via In-App + Mail, SMS nur kritisch
  • Test-Versand vor Produktiv — eigenes Postfach
  • Provider-Limits im Blick — SMS sind teuer, Mails haben Tagesquotas

KI-Chat-Anwendungen

Welche Notifications wurden in den letzten 24h versendet? Pro Channel
mit Anzahl, Empfänger, Status (gesendet/bounced/gelesen).
Welche Mitarbeiter haben sich für ZU VIELE Notifications eingeschrieben
(>10/Tag)? Möglicherweise Spam-Ermüdung.

Verwandte Doku