Je workflow stopt. Wie weet wat er nu moet gebeuren?

Een automatisering haalt een aanvraag op, maakt een intern taakrecord en zet een bevestiging klaar. Halverwege gaat het mis. Een rode uitvoering vertelt de bouwer dat er iets is gestopt. Voor het team blijven andere vragen over: is de aanvraag bewaard, is er al iets verstuurd en wie pakt dit op?

Ontwerp daarom naast de gewone route ook de route voor wanneer het fout gaat. Hieronder staat een voorstel voor die inrichting, met fictieve gegevens. Het is geen verslag van een geteste productieomgeving. Een foutmelding is pas bruikbaar als iemand ermee kan bepalen wat veilig hersteld kan worden.

Maak de melding klein, maar beslisbaar

n8n kan een aparte errorworkflow starten wanneer een gekoppelde workflowuitvoering faalt. Die begint met een Error Trigger en wordt in de instellingen van de hoofdworkflow geselecteerd. De ontvangen foutinformatie kan onder meer de workflownaam en gegevens over de mislukte uitvoering bevatten. Niet ieder fouttype bevat dezelfde velden: bij een fout in de trigger kunnen een execution-ID en uitvoeringslink ontbreken.

• Wat is gestopt? Een herkenbare procesnaam en de fase waar het misging.
• Wat weten we over de gevolgen? Apart vermelden wat bevestigd is en wat nog onderzocht moet worden.
• Waar is bewijs te vinden? Een beschikbare uitvoeringslink of een veilig referentienummer, zonder volledige klantinhoud.
• Wie onderzoekt het? Eén afgesproken eigenaar of intern team, met een concrete controle als volgende stap.

Een volledig bronbericht naar een breed meldingskanaal kopiëren is meestal geen goede diagnose. Ontwerp de melding met minimale gegevens. Bewaar technische details in een omgeving met passende toegang. Vermijd wachtwoorden, tokens en complete aanvraaginhoud in foutteksten.

Werk één fout van begin tot einde uit

INVOER
Fictieve aanvraag DEMO-042 moet een intern taakrecord krijgen. De route bestaat uit: aanvraag lezen, taakrecord maken, bevestiging voorbereiden.

WAARNEMING
Het maken van het taakrecord geeft een time-out. Er is geen bevestigd resultaat beschikbaar. De stap voor het voorbereiden van de bevestiging is niet gestart.

BRUIKBARE MELDING
Aanvraagverwerking DEMO-042 gestopt bij taakrecord maken. Uitkomst van die schrijfactie onbekend. Bevestigingsstap niet gestart. Controleer eerst of het taakrecord al bestaat. Eigenaar: beheerder van de aanvraagroute.

HERSTELBESLUIT
Pas na controle van het doelsysteem bepalen of de schrijfactie nog nodig is. Geen volledige herstart op basis van de time-out alleen.

Het verschil zit in de formulering “uitkomst onbekend”. Een time-out bewijst niet dat het doelsysteem niets heeft gedaan. Als het taakrecord wel is gemaakt, kan een volledige herstart een tweede record opleveren. Het errorpad bewaart daarom eerst de onderzoeksvraag. De uitvoerder beslist pas daarna over herstel.

Laat een inhoudelijke grens bewust stoppen

Niet iedere ongewenste uitkomst veroorzaakt vanzelf een technische fout. Een aanvraag kan bijvoorbeeld wel binnenkomen, maar geen geldig projectkenmerk bevatten. n8n heeft hiervoor Stop And Error: daarmee kun je onder zelfgekozen omstandigheden een uitvoering laten falen, met een eigen foutbericht of foutobject. De grens moet je zelf definiëren.

REGEL
Een taakrecord mag alleen worden voorbereid wanneer de aanvraag precies één bekend projectkenmerk bevat.

GOEDE INVOER
DEMO-042 met projectkenmerk PROJECT-A: ga verder in de testomgeving.

AFWIJKENDE INVOER
Geen projectkenmerk: stop vóór de schrijfactie.
Twee tegenstrijdige kenmerken: stop en vraag om beoordeling.

FOUTTEKST
Projectkoppeling ontbreekt of is niet eenduidig. Geen taakrecord aangevraagd. Controleer de broninvoer.

Schrijf alleen “geen taakrecord aangevraagd” wanneer de controle daadwerkelijk vóór die actie staat. Een prettige fouttekst mag de echte uitvoeringsvolgorde niet verhullen. Maak daarnaast onderscheid tussen een verwachte afwijzing en een storing: beide kunnen aandacht vragen, maar niet noodzakelijk met dezelfde urgentie.

Test ook de route die je zelden ziet

1. Bouw een aparte testkopie met fictieve input. Vervang externe schrijfacties en berichten door veilige testdoelen.
2. Koppel de errorworkflow en forceer één bekende fout. De Error Trigger reageert volgens n8n op fouten in automatische uitvoeringen, niet op een handmatige workflowrun. Test dus ook die automatische route in een afgeschermde testopstelling.
3. Controleer de ontvangen melding bij een gewone nodefout én bij ontbrekende uitvoeringsgegevens. Een ontbrekende link moet herkenbare tekst opleveren, geen kapotte melding.
4. Controleer wie de melding ontvangt, hoeveel gegevens erin staan en of die persoon de diagnoseplek kan openen.
5. Laat een collega uitsluitend met die melding uitleggen wat er is gebeurd en wat de eerstvolgende veilige stap is. Pas de melding aan als die uitleg ontbreekt.

Een herstelde hoofdworkflow is nog geen bewijs dat de meldingsroute werkt. Test ook wat er gebeurt als de melding zelf niet aankomt. Spreek af waar je mislukte uitvoeringen periodiek controleert en voorkom dat een kapotte meldingsroute eindeloos zichzelf probeert te waarschuwen.

Maak herstel een afzonderlijke beslissing

Leg voor iedere belangrijke route vast wie een herstart mag doen en welke controle eraan voorafgaat. Een leesactie opnieuw proberen vraagt iets anders dan een factuur, mail of CRM-record opnieuw aanmaken. Een errorworkflow kan bewijs en context verzamelen. Geef hem niet ongemerkt toestemming om iedere mislukte stap opnieuw uit te voeren.

Begin klein: kies één belangrijke workflow, maak één foutmelding beslisbaar en test één onzekere uitkomst. Daarmee weet je bij de volgende storing niet alleen dát er iets misging, maar ook waar het onderzoek begint.

Beeld: AI-gegenereerde clay-illustratie; een visuele metafoor, geen technisch schema of productscreenshot.