E-Mail in SuiteCRM 8: UI, Scheduler und Workflows
- „Testmail aus Admin ok“ prüft vor allem den interaktiven Pfad – nicht automatisch denselben Pfad wie Scheduler oder Workflow.
- Nach Minor-Upgrades ändern sich Anforderungen an Queues, gespeicherte SMTP-Daten oder Job-Ausführung; Forenberichte dazu sind zahlreich und versionsabhängig.
- Stabile E-Mail ist ein Betriebsprodukt aus CRM-Konfiguration, OS-Cron, Provider-Limits und fachlicher Flow-Logik.
„Blackbox“-Versand
Queue, Status, Diagnose
Provider-Limits und Massenversand
Viele SMTP-Anbieter drosseln oder blockieren ab bestimmten Kontingenten. Ohne Warteschlange und Fehlerbehandlung bricht der Restlauf ab oder erzeugt schwer rekonstruierbare Lücken. Zahlen und Limits sind anbieterabhängig – in der Doku des Providers und im eigenen Monitoring nachlesen.
E-Mail ist in SuiteCRM kein einzelnes Feature, sondern eine Schnittstelle zwischen Benutzeroberfläche, Hintergrundverarbeitung und externem Mail-Provider. Genau deshalb sind Fehlermeldungen aus dem Alltag oft widersprüchlich: Manuell geht’s, automatisch nicht.
1. Drei Pfade, die Teams vermischen
| Pfad | Auslösung | Woran er hängt | Typisches Trugschluss |
|---|---|---|---|
| UI / Compose / Admin-Test | Mensch klickt jetzt | Session, Rechte, aktuelles Outbound-Konto | „SMTP ist global in Ordnung“ |
| Scheduler | Cron / geplante Jobs | OS-Cron, Job-Status, CLI-User, Queue | „Cron läuft, also laufen Mails“ |
| Workflow | Save oder zeitgesteuert | Trigger-Timing, Bedingungen, Mail-Aktion im Flow | „Flow ist aktiv, also wird gesendet“ |
2. Outbound-Konto als Single Point of Confusion
Viele Instanzen haben mehrere Outbound-Einträge, historische Systemkonten und benutzerbezogene Absender. Nach Upgrades berichten Admins gelegentlich, dass UI-Tests funktionieren, während gespeicherte Credentials in Hintergrundkontexten nicht mehr greifen (z. B. nach Provider-Wechsel auf längere SMTP-Passwörter oder nach Dateninkonsistenzen in Outbound-Tabellen). Die robuste Reaktion ist nicht „Passwort 20-mal neu tippen“, sondern:
- Welches Konto ist für System-/Job-Mails vorgesehen?
- Ist genau dieses Konto im Job-Kontext referenziert?
- Wurde das Konto nach dem Upgrade bewusst neu gespeichert und verifiziert?
- Unterscheiden sich Fehler in UI-Log und Job-Zeitfenster?
3. Scheduler: der stille Ausfall
Wenn Cron auf OS-Ebene hängt, Jobs auf „completed“ mit Null-Wirkung stehen oder der Webserver-User von CLI-Rechten abweicht, sterben Erinnerungen und workflow-getriggerte Mails zuerst – nicht der manuelle Versand. Prüfraster:
- Crontab / Systemd-Timer dokumentiert und dem richtigen User zugeordnet
- Admin → Scheduler: kritische Jobs aktiv, Last-Run plausibel
- Nach Upgrade: neue Anforderungen (z. B. Messenger/Worker laut Release) gelesen und umgesetzt
4. Workflow-Mails: Logik vor SMTP
Bevor Sie den Provider beschuldigen: Läuft der Flow zu einem Zeitpunkt, zu dem Related Contacts noch nicht verknüpft sind? Ist die Bedingung an einem Feld, das im UI-Prozess später gesetzt wird? Bleibt die Instanz auf „running“, während andere Aktionen klappen? Das sind Designfehler im Flow – SMTP-Tests in der Admin-UI finden sie nicht.
5. Diagnose-Reihenfolge (praktisch)
- Reproduzieren: ein kontrollierter Datensatz, ein bekannter Empfänger (interne Adresse).
- UI-Testmail vom vorgesehenen Systemkonto.
- Denselben Versand über den Job-/Workflow-Pfad anstoßen.
- Logs im Zeitfenster (CRM + MTA/Provider, falls zugänglich).
- Erst dann Provider, Firewall, SPF/DKIM – sonst optimieren Sie die falsche Schicht.
SuiteSMTP in SuiteUltimate zielt auf nachvollziehbareren Versand und bessere Sichtbarkeit im CRM-Kontext. Es ersetzt weder OS-Cron noch saubere Flow-Modellierung. Für Teams mit vielen automatischen Mails ist Sichtbarkeit oft der größte Hebel vor der nächsten „SMTP neu konfigurieren“-Schleife.
SuiteSMTP ↗Fazit: Behandeln Sie E-Mail als drei Systeme in einem Label. Wer nur den Admin-Test kennt, kennt das System nicht.