Wat doet Make als er niets is ingericht?

Bouw je een scenario zonder foutafhandeling, dan gebruikt Make standaard het gedrag van de Rollback-handler. Volgens de helpdocumentatie van Make (gecontroleerd op 13 oktober 2026) betekent dat: het scenario stopt bij de fout, de run krijgt de status Error en wijzigingen in modules die transacties ondersteunen worden teruggedraaid.

Daar blijft het niet bij. Make telt opeenvolgende mislukte runs:

  • Geplande scenario's worden standaard uitgeschakeld na drie fouten op rij. Dat aantal kun je aanpassen in de scenario-instellingen.
  • Scenario's met een directe trigger, zoals een webhook, worden volgens Make al bij de eerste fout uitgeschakeld.
  • Bij een paar fouttypes, zoals een ongeldige koppeling of een opgebruikt tegoed, schakelt Make het scenario meteen uit, ongeacht het aantal.

Dat uitschakelen is bedoeld als bescherming: je wilt niet dat een kapot scenario honderd keer per uur dezelfde fout maakt. Maar het gevolg is wel dat een workflow waar je op rekent ineens niets meer doet. Facturen worden niet meer aangemaakt, leads komen niet meer in het CRM, en niemand merkt het tot een klant belt.

Welke error handlers heeft Make en wanneer gebruik je welke?

In Make hang je een error handler aan een module. Gaat die module fout, dan volgt het scenario de foutroute in plaats van te stoppen. Make kent vijf handlers. In oudere documentatie en tutorials kom je twee ervan nog onder een andere naam tegen.

Skip (voorheen Ignore)

Het bundle met de fout wordt overgeslagen en de rest van het scenario gaat door. De run eindigt als Success. Handig als één mislukt record niet erg is, bijvoorbeeld een nieuwsbriefinschrijving met een ongeldig e-mailadres. Gevaarlijk als je hem overal neerzet: dan zie je fouten nergens meer terug.

Retry (voorheen Break)

Het mislukte bundle wordt bewaard als incomplete execution, de rest van het scenario loopt door en de run krijgt de status Warning. Je kunt Make het bundle automatisch opnieuw laten proberen, met een aantal pogingen en een interval, of het handmatig opnieuw starten. Dit is de handler voor tijdelijke problemen, zoals een API die even niet bereikbaar is of een limiet op het aantal verzoeken. Retry werkt alleen als het bewaren van incomplete executions aanstaat.

Resume

Je geeft een vervangende waarde op voor de output van de mislukte module en het scenario gaat verder alsof er niets aan de hand was. Status: Success. Bruikbaar voor niet-kritische velden, bijvoorbeeld een standaard categorie als een opzoekactie niets vindt. Gebruik het niet voor bedragen of btw-codes.

Commit

Het scenario stopt, maar wat al verwerkt is blijft staan. Status: Warning.

Rollback

Het scenario stopt en Make draait wijzigingen in transactie-ondersteunende modules terug. Status: Error. Dit is ook het standaardgedrag zonder handler.

Goed om te weten: volgens Make verbruikt een error handler die afgaat geen credits. Foutafhandeling inbouwen kost je dus geen extra tegoed.

Welke scenario-instellingen zijn belangrijk voor foutafhandeling?

Naast de handlers per module zijn er een paar instellingen op scenarioniveau die bepalen hoe Make met fouten omgaat. Je vindt ze in de scenario-instellingen.

  • Incomplete executions bewaren. Staat dit aan, dan bewaart Make een mislukte run met de data erbij, zodat je die kunt onderzoeken en opnieuw kunt starten. Voor elk scenario dat met geld, klanten of orders te maken heeft, zet je dit aan.
  • Aantal opeenvolgende fouten. Bepaalt na hoeveel mislukte runs op rij een gepland scenario wordt uitgeschakeld. Standaard drie. Hoger zetten verschuift het probleem alleen; zorg liever dat je de fout op tijd ziet.
  • Data in volgorde verwerken. Met deze instelling wacht een nieuwe run tot de vorige klaar is en tot openstaande incomplete executions zijn opgelost. Dat is nuttig als volgorde ertoe doet, maar een onopgeloste fout houdt dan ook alle volgende runs tegen.
  • Data vertrouwelijk houden. Make bewaart dan geen inhoud van de runs. Goed voor gevoelige gegevens, maar volgens Make heb je dan weinig mogelijkheden om fouten te onderzoeken. Maak die afweging bewust.

Hoe zorg je dat iemand een fout ook echt ziet?

De beste error handler helpt niet als niemand kijkt. Een foutroute kan zelf modules bevatten, en daar maak je gebruik van: zet aan het eind van de foutroute een module die een bericht stuurt naar een Teams-kanaal of een mailbox die echt gelezen wordt.

Zet in dat bericht minstens:

  1. de naam van het scenario en de module die faalde;
  2. de foutmelding;
  3. om welk record het gaat, bijvoorbeeld het ordernummer of de klantnaam;
  4. wat de ontvanger moet doen, of waar de instructie staat.

Spreek daarnaast één eigenaar per scenario af. Niet "het team", maar een naam. Die persoon kijkt bij een melding binnen een afgesproken tijd, en loopt eens per maand de incomplete executions en de scenariohistorie langs. Meer over eigenaarschap en het kiezen van je eerste processen lees je in workflow automation: 7 processen die je als eerste automatiseert.

Voorbeeld: foutafhandeling in een orderscenario

Een fictief voorbeeld. Een groothandel met een webshop laat Make elke betaalde order als verkoopfactuur in het boekhoudpakket zetten. Dat is scenario 2 uit Make.com workflows voor het mkb. Zo richt je de foutafhandeling in:

  1. Zet incomplete executions aan. Een order die niet doorkomt, mag nooit verdwijnen.
  2. Retry op de module die de factuur aanmaakt. Is het boekhoudpakket even niet bereikbaar, dan probeert Make het later opnieuw, bijvoorbeeld drie keer met een kwartier ertussen.
  3. Geen Resume op btw of bedragen. Vindt het scenario geen passende btw-code, dan wil je geen standaardwaarde, maar een mens die kijkt.
  4. Melding in de foutroute. Na de Retry-handler stuurt het scenario een bericht naar het Teams-kanaal van de administratie, met ordernummer en foutmelding.
  5. Een controle aan het eind van de week. Een klein gepland scenario telt de betaalde orders in de webshop en de aangemaakte facturen in de boekhouding. Wijken die af, dan volgt een melding. Zo vang je ook fouten die geen foutmelding gaven, zoals orders die door een filter vielen.

Die laatste stap wordt vaak vergeten. Een scenario kan netjes Success melden en toch niet doen wat je verwacht, bijvoorbeeld als een API een lege lijst teruggeeft of een filter te streng staat. Tellen aan beide kanten is dan de enige manier om het te zien.

Welke fouten zien we het vaakst in Make-scenario's?

  • Overal Skip. Het scenario draait altijd groen, maar er verdwijnen records zonder dat iemand het weet.
  • Meldingen naar een persoonlijke mailbox. Die persoon is op vakantie of werkt er niet meer, en de meldingen lopen dood.
  • Geen bewaarde runs. Zonder incomplete executions moet je bij een fout uitzoeken welke data niet is verwerkt en die met de hand nalopen.
  • Dezelfde logica in vijf scenario's. Als meerdere scenario's dezelfde gegevens ophalen en omzetten, moet je fouten ook op vijf plekken afvangen. Dan is een centraal datafundament vaak de betere basis.
  • Geen test met foute data. Test niet alleen het normale pad. Stuur bewust een record met een ontbrekend veld of een onbekende klant door het scenario en kijk wat er gebeurt.

Twijfel je of Make wel het juiste platform is voor je workflows, lees dan Make vs n8n.

Hulp bij foutafhandeling in je Make-scenario's?

Heb je scenario's draaien waarvan je niet zeker weet of ze nog doen wat ze moeten doen, of wil je nieuwe scenario's meteen goed opzetten? We bouwen Make-scenario's met foutafhandeling, meldingen en documentatie, en kijken ook graag naar wat er al staat. Bekijk wat we doen op het gebied van workflow automation, welke systemen we vaak koppelen en hoe we werken.