De workflowtrigger staat aan. Dat betekent nog niet dat de flow heeft gedraaid.

Het is de eerste werkdag van de maand. Om zes uur ’s ochtends moet een flow automatisch een betalingsherinnering sturen naar elke klant met een openstaande factuur. Om tien uur vraagt de financiële afdeling waarom nog geen enkele klant heeft gereageerd.

Iemand opent de flow. De planning staat aan. Er wordt geen foutmelding getoond.

Vervolgens opent iemand de lijst met runs. Daar staat geen enkele run van die ochtend.

Het scherm gaf geen onjuiste informatie. Het beantwoordde alleen de vraag: ‘Staat de planning aan?’ Het team had antwoord nodig op een andere vraag: ‘Heeft de flow daadwerkelijk gedraaid?’

Eén gebruiker meldde dat een webhooktrigger als actief werd weergegeven, zowel in de interface als in de database, terwijl het platform binnenkomende aanroepen weigerde. De oplossing bleek de toegangsgegevens te verwijderen en opnieuw aan te maken. Alles leek gekoppeld en correct ingesteld.

Een andere gebruiker meldde dat geplande workflows niet meer draaiden, hoewel ze overal als actief werden weergegeven. De lijst met activeringsfouten was leeg. De enige manier die de gebruiker vond om de planning weer te laten werken, was elke workflow opnieuw opslaan.

Een derde gebruiker meldde dat een e-mailtrigger stopte nadat de workflow was gepubliceerd. Er kwamen nieuwe e-mails binnen, maar er verscheen geen nieuwe run in de lijst. Nadat de workflow offline was gehaald en opnieuw was gepubliceerd, werkte de trigger weer.

Een team dat een pipeline volgens planning uitvoert zonder dat iemand de runs actief controleert, meldde dat de pipeline dagenlang bij elke run was mislukt voordat iemand dat opmerkte.

In reactie op een vergelijkbare melding werd een controle voorgesteld die buiten het platform plaatsvindt: vergelijk bij elke geplande workflow de laatste run met het aantal runs dat u zou verwachten. Beschouw het uitblijven van runs als een waarschuwing.

Vier meldingen, één patroon. Iets gaf aan dat een trigger ‘aan’ of ‘actief’ was. Alleen de runhistorie liet zien wat er daadwerkelijk was gebeurd.

Een flow met AI agents start niet vanzelf. Er moet iets zijn dat de flow start. In EpicStaff kan dat op vijf manieren: handmatig of via de API, volgens een planning, via een webhookaanroep, via een Telegram-bericht of vanuit een bovenliggende flow.

Niet elke trigger heeft dezelfde betekenis van ‘aan’. De trigger maakt deel uit van de harness, de runtime-laag waarin uw agents draaien, en niet van het model zelf. Lees meer in Wie controleert de agent-harness?

Leg daarom voor elke flow eerst vast waardoor deze wordt gestart.

De vier controles hieronder zijn geschikt voor elk platform, ook voor EpicStaff. Onder elke controle leest u wat EpicStaff laat zien. Als het platform geen antwoord geeft, vermelden we dat duidelijk en moet u zelf een controle inrichten. Deze controles zijn een aanvulling op de vragen die u aan elke leverancier stelt voordat u zelf software host.

Controleer wat ‘aan’ of ‘actief’ op uw platform precies betekent. Het kan betekenen dat de trigger klaarstaat om te worden geactiveerd. Het kan ook betekenen dat de trigger daadwerkelijk is geactiveerd. Dat is niet hetzelfde.

In EpicStaff hebben alleen planningstriggers een aan-uitknop. ‘Aan’ betekent dat de planning is ingeschakeld, niet dat er een run is gestart. Webhook- en Telegram-triggers hebben geen schakelaar. Ze starten de flow zodra er een geldige aanroep binnenkomt.

Bij een planning vertelt de schakelaar dus wat u hebt ingesteld. Bij een webhook- of Telegram-trigger moet u iets anders controleren: komen er nog geldige aanroepen binnen? Controleer dit bij het systeem dat de aanroepen verstuurt. Verstuurt dat systeem nog steeds berichten naar het juiste adres, met de juiste geheime sleutel?

Hoe u in een noodgeval één flow stopt: De workflow die alles meesleepte in zijn val.

Een planning hoort te tonen wanneer deze de volgende keer wordt uitgevoerd. Vergelijk dat tijdstip met de huidige tijd en met de planning die u hebt ingesteld. Controleer ook of de juiste tijdzone wordt gebruikt.

In EpicStaff toont een planningstrigger wanneer deze de volgende keer wordt uitgevoerd en hoe vaak de trigger al is afgegaan. Het tijdstip waarop de trigger voor het laatst is afgegaan, wordt niet getoond. Dat vindt u in de lijst met runs van de flow.

Noteer hoeveel runs er zijn wanneer u de controle uitvoert. Is het geplande tijdstip verstreken en is het aantal runs niet veranderd? Open dan de lijst met runs.

Controleer ook het tijdstip van de volgende run. Als het starten van een geplande run mislukt, worden het aantal runs en het tijdstip van de volgende run niet bijgewerkt. Het scherm kan de planning dan nog steeds als ingeschakeld tonen, terwijl het tijdstip van de volgende run al verstreken is. Dat is een reden om de lijst met runs te controleren.

Houd ook rekening met serveruitval. Als de EpicStaff-server niet beschikbaar is op een gepland tijdstip, wordt die run overgeslagen. De run wordt niet later alsnog uitgevoerd en er wordt geen registratie bijgehouden die een gebruiker kan bekijken. Richt daarom zelf een controle in. Bekijk na elke herstart of onderhoudsperiode welke geplande runs in die periode vielen en bepaal welke u handmatig moet starten.

De lijst met runs geeft antwoord op deze vraag. Bekijk die lijst altijd samen met de planning. Een lijst zonder mislukte runs kan nog steeds een run missen die nooit is gestart.

EpicStaff waarschuwt u niet wanneer het starten van een geplande run mislukt. U moet daarom zelf een controle inrichten.

Dat betekent dat u de runs moet tellen, niet alleen de lijst moet bekijken. Noteer voor elke geplande flow hoeveel runs u per dag of per week verwacht. Vergelijk dat aantal dagelijks met de lijst met runs. Ontbreekt er een run, dan is dat uw waarschuwing. Een telling die niemand controleert, biedt geen zekerheid.

Een run in de lijst is niet altijd de run die u verwachtte. Een collega kan de flow handmatig hebben gestart tijdens een test. Ook kan een bovenliggende flow de run hebben gestart. Als u alleen het totale aantal runs telt, kan een testrun verhullen dat een geplande run ontbreekt.

In EpicStaff wordt bij elke run vastgelegd waardoor deze is gestart. U kunt dat terugvinden in de lijst met runs van de flow en in de JSON-export.

Tel bij het controleren van een planning daarom alleen de runs die door de planning zijn gestart. Controleer bij een webhook alleen de runs die door de webhook zijn gestart.

Voor webhooks moet ook het verzendende systeem een eigen registratie bijhouden. Als een webhookaanroep naar een bekend adres wordt gestuurd met de juiste geheime sleutel, geeft EpicStaff direct de status ‘ontvangen’ terug, nog voordat er een run is gestart. De aanroep krijgt geen run-id en geeft niet aan of de run daarna mislukt. Richt daarom zelf een controle in. Laat het verzendende systeem elke aanroep registreren en vergelijk vervolgens het aantal aanroepen met het aantal runs dat door een webhook is gestart.

Bij drie van de bovenstaande controles moet u zelf een controle inrichten. Met één eenvoudig controlemechanisme kunt u ze alle drie afdekken:

• Houd een lijst bij van alle flows, waardoor ze worden gestart en hoeveel runs u per dag verwacht.
• Vergelijk deze lijst dagelijks met de lijst met runs. Begin handmatig en automatiseer dit wanneer de lijst groeit.
• Vergelijk bij flows die via webhooks worden gestart het aantal aanroepen bij de afzender met het aantal runs dat door een webhook is gestart.
• Stuur waarschuwingen naar een specifiek aangewezen persoon, niet naar een gedeeld kanaal dat mogelijk niemand leest.
• Laat het controlemechanisme draaien op een andere server dan de server die het bewaakt. Als beide op dezelfde server draaien, valt de controle uit wanneer die server uitvalt.

Controle	Waar EpicStaff antwoordt	Wat u toevoegt
Staat de trigger aan?	Planningen: de aan/uitschakelaar, die betekent dat de planning is aangezet. Webhook- en Telegram-triggers: geen schakelaar; ze starten de flow zodra er een geldige aanroep binnenkomt.	Controleer of de afzender nog verstuurt.
Wanneer staat de volgende run gepland?	De planningstrigger toont wanneer deze de volgende keer wordt uitgevoerd en hoe vaak de trigger al is afgegaan.	De tijdzone, het aantal runs toen u keek, en een lijst van tijdstippen die in een storing vielen.
Heeft hij gelopen?	De lijst met runs van de flow.	Houd buiten het platform dagelijks bij hoeveel runs u verwacht en vergelijk dit met de lijst.
Waardoor is de run gestart?	De lijst met runs en de JSON-export leggen vast wat elke run startte.	Houd bij het verzendende systeem een eigen logboek bij van webhookaanroepen.

Vul deze vier regels in voor elke flow. Als u de informatie niet kunt invullen, vertrouwt u erop dat de schakelaar het juiste beeld geeft, zonder te controleren of de flow daadwerkelijk draait.