Workflows: bij opslaan of scheduler?
- Workflows bij opslaan draaien in het opslagverzoek – relaties en vervolgobjecten zijn vaak nog niet vastgelegd.
- Schedulerworkflows ontkoppelen interface en werk, maar vereisen cron, observatie en idempotentie.
- Verkeerde modellering blijkt uit ‘lege’ e-mails, hangende verzoeken of dubbele acties – niet uit een abstracte theoretische fout.
Workflows in SuiteCRM (historisch Advanced Open Workflow) bieden voorwaardelijke acties op moduleniveau. In de praktijk falen ze minder vaak door ‘de engine’, maar door onjuiste aannames over het tijdstipwaarop gegevens volledig zijn en relaties vastliggen. Dit artikel maakt de architectuurkeuze concreet – met keuzehulp, levenscyclusvergelijking en testchecklist.
Welk workflowtype past bij uw situatie?
Twee vragen – één advies. Geen vervanging voor stagingtests, maar een filter tegen de meest voorkomende verkeerde keuze.
Geschikt voor berekeningen of statuswijzigingen bij hetzelfde record, zonder afhankelijke relaties en zonder merkbare wachttijd.
1. Twee levenscycli – synchroon versus asynchroon
In plaats van abstracte definities bekijken we het verloop dat gebruiker en systeem werkelijk ervaren:
Levenscyclus bij opslaan
- 1 Gebruiker klikt op ‘Opslaan’
- 2 HTTP-verzoek draait – browser wacht
- 3 Validatie & hooks vóór opslaan
- 4 Databaseschrijfactie (INSERT/UPDATE)
- 5 Workflow bij opslaan: eventueel e-mails, webhooks, extra schrijfacties
- 6 Antwoord naar de browser
Schedulerlevenscyclus
- 1 Gebruiker slaat op – snel antwoord
- 2 Interface is weer bedienbaar
- 3 In de tijd ontkoppeld: cron/worker
- 4 Taak leest actuele databasetoestand (relaties doorgaans aanwezig)
- 5 Batchacties zonder interfaceblokkade
- 6 Status-/idempotentievlag zetten
2. Keuzehulp in het kort
| Ontwerpvraag | Eerder bij opslaan | Eerder scheduler |
|---|---|---|
| Ontstaat het gerelateerde record pas na opslaan? | ongunstig | geschikt |
| Heeft de gebruiker een direct zichtbaar veld/antwoord nodig? | geschikt | vertraagd |
| Externe API met merkbare vertraging? | riskant in het verzoek | beter |
| Grote hoeveelheden / nachtelijke uitvoeringen? | ongeschikt | met filters plannen |
3. Drie architectuurvalkuilen
De subpaneelillusie
Het ID van het hoofdrecord kan in de opslagcontext al bestaan, terwijl gekoppelde records (subpaneelrelaties) pas in een latere transactiestap of daarna worden geschreven. Een workflow bij opslaan die ‘contact bij de offerte’ verwacht, vindt dan niets – hoewel de gebruiker de koppeling zojuist in de interface heeft ingesteld. Tegenmaatregel: Scheduler of een bewuste tweede stap zodra de relatie gegarandeerd leesbaar is.
De recursieve eindeloze lus
Workflow wijzigt een veld → start opnieuw opslaan → workflow draait weer → tot time-out of geheugenlimiet. Vooral verraderlijk als voorwaarde en schrijfdoel hetzelfde veld betreffen. Tegenmaatregel: expliciete verwerkingsvlag, voorwaarden zo formuleren dat de tweede uitvoering niets doet, geen onnodige opslagacties in de keten.
De ongeremde scheduleruitvoering
Een schedulerproces zonder strikte datum-/statusfilters kan na jaren gebruik bij elke cronuitvoering enorme oude hoeveelheden raken. Het systeem lijkt ‘plotseling traag’, terwijl het proces ‘altijd al zo was’. Tegenmaatregel: strikte selectiecriteria, status ‘reeds verwerkt’, looptijden en belasting bewaken.
4. Gereed voor productie: afvinkbaar testprotocol
Productieactivering zonder deze vijf bewijzen is blind varen – ongeacht het gekozen triggertype.
Stagingchecklist
De Workflow Engine in AgenticUltimate gebruikt visuele modellering, simulatie en versiebeheerde vrijgave – zodat processen niet ongezien in productie komen. De inhoudelijke keuze tussen bij opslaan en scheduler blijft een architectuurbeslissing; simulatie vervangt geen van de vijf bovenstaande controles.
Workflow Engine ↗5. Grenzen van dit artikel
Geen garantie voor elke SuiteCRM-patchversie of elk maatwerkhooklandschap. De adviezen zijn architectuurvuistregels uit typische foutbeelden – staging op uw installatie blijft bepalend.