Workflows: On Save oder Scheduler?
- On-Save-Flows laufen im speichernden Request – Relationships und Folgeobjekte sind oft noch nicht gesetzt.
- Scheduler-Flows entkoppeln UI und Arbeit, brauchen aber Cron, Beobachtung und Idempotenz.
- Falsche Modellierung zeigt sich als „leere“ Mails, hängende Requests oder doppelte Aktionen – nicht als abstrakter Theoriefehler.
Workflows in SuiteCRM (historisch Advanced Open Workflow) erlauben bedingte Aktionen auf Modulebene. In der Praxis scheitern sie seltener an „der Engine“, sondern an falschen Annahmen über den Zeitpunkt, zu dem Daten vollständig und Beziehungen gesetzt sind. Dieser Artikel macht die Architekturentscheidung greifbar – mit Entscheidungshilfe, Lifecycle-Vergleich und Test-Checkliste.
Welcher Workflow-Typ passt zu Ihrem Fall?
Zwei Fragen – eine Empfehlung. Kein Ersatz für Staging-Tests, aber ein Filter gegen die häufigste Fehlentscheidung.
Geeignet für Berechnungen oder Statusänderungen am selben Datensatz, ohne abhängige Relationships und ohne spürbare Wartezeit.
1. Zwei Lebenszyklen – synchron vs. asynchron
Statt abstrakter Definitionen der Blick auf den Ablauf, den Benutzer und System tatsächlich erleben:
On-Save-Lifecycle
- 1 Benutzer klickt „Speichern“
- 2 HTTP-Request läuft – Browser wartet
- 3 Validierung & Before-Save-Hooks
- 4 Datenbank-Write (INSERT/UPDATE)
- 5 On-Save-Workflow: ggf. Mails, Webhooks, weitere Writes
- 6 Response an den Browser
Scheduler-Lifecycle
- 1 Benutzer speichert – Antwort zügig
- 2 UI ist wieder bedienbar
- 3 Zeitlich entkoppelt: Cron/Worker
- 4 Job liest aktuellen DB-Zustand (Relationships i. d. R. vorhanden)
- 5 Batch-Aktionen ohne UI-Blockade
- 6 Status-/Idempotenz-Flag setzen
2. Entscheidungshilfe in Kurzform
| Designfrage | Eher On Save | Eher Scheduler |
|---|---|---|
| Related Record entsteht erst nach dem Save? | ungünstig | geeignet |
| User braucht sofort sichtbares Feld/Feedback? | geeignet | verzögert |
| Externe API mit spürbarer Latenz? | riskant im Request | besser |
| Große Mengen / nächtliche Läufe? | ungeeignet | mit Filtern planen |
3. Drei Architektur-Fallen
Die Subpanel-Illusion
Die ID des Hauptdatensatzes kann im Save-Kontext bereits existieren, während verknüpfte Datensätze (Subpanel-Relationships) erst in einem späteren Schritt der Transaktion bzw. nachgelagert geschrieben werden. Ein On-Save-Flow, der „Kontakt am Angebot“ erwartet, greift dann ins Leere – obwohl der Benutzer die Verknüpfung in der UI gerade gesetzt hat. Gegenmaßnahme: Scheduler oder bewusster zweiter Schritt, sobald die Relation garantiert lesbar ist.
Die rekursive Todesschleife
Workflow ändert ein Feld → löst erneut Save aus → Workflow läuft wieder → bis Timeout oder Speichergrenze. Besonders tückisch, wenn Bedingung und Schreibziel dasselbe Feld betreffen. Gegenmaßnahme: explizites Verarbeitungs-Flag, Bedingungen so formulieren, dass der zweite Lauf no-op ist, keine unnötigen Saves in der Kette.
Der ungebremste Scheduler-Lauf
Ein Scheduler-Flow ohne enge Datums-/Statusfilter kann nach Jahren Betrieb bei jedem Cron-Durchlauf enorme Altmengen anfassen. Das System wirkt „plötzlich langsam“, obwohl der Flow „schon immer so war“. Gegenmaßnahme: enge Selektionskriterien, Status „bereits verarbeitet“, Laufzeiten und Last beobachten.
4. Deployment-Readiness: Testprotokoll zum Abhaken
Produktivschaltung ohne diese fünf Nachweise ist Blindflug – unabhängig vom gewählten Trigger-Typ.
Checkliste Staging
Die Workflow Engine in AgenticUltimate setzt auf visuelle Modellierung, Simulation und versionierte Freigabe – damit Flows nicht „ungesehen“ produktiv werden. Die fachliche Wahl On Save vs. Scheduler bleibt eine Architekturentscheidung; Simulation ersetzt keine der fünf Checks oben.
Workflow Engine ↗5. Grenzen dieses Artikels
Keine Garantie für jeden SuiteCRM-Patchstand oder jede Custom-Hook-Landschaft. Die Empfehlungen sind Architekturheuristiken aus typischen Fehlerbildern – Staging an Ihrer Instanz bleibt maßgeblich.