Make-scenario maken en testen zonder dubbele runs (2026)

Een Make-scenario test je veilig door één trigger, één testrecord en één controleerbare bestemming te gebruiken. Zet planning en retries pas aan wanneer dezelfde trigger niet tot dubbele resultaten leidt.

Stappenplan

1. Kies één scenario-uitkomst

Beschrijf een onschadelijk resultaat, zoals één testtaak in een testlijst. Begin met een terugkerende taak inventariseren als bron, trigger en eigenaar nog niet helder zijn.

2. Bouw één trigger en één actie

Gebruik eerst zo min mogelijk modules. Make legt de basis van scenario's en runs uit in zijn helpcentrum. Controleer in elke module alleen de vaste mapping, niet met echte klant- of toegangsgegevens.

3. Kies een unieke sleutel vóór je plant

Leg vast hoe de bestemming herkent dat een bronrecord al verwerkt is. De route voor dubbele data en datamapping helpt je die test opzetten. Een tijdstip van de run is meestal geen stabiele sleutel.

4. Herhaal dezelfde test bewust

Start dezelfde veilige trigger twee keer. Verwacht je één resultaat, dan moet de tweede run zichtbaar worden afgehandeld zonder nieuw record. Zie je twee uitvoeren, herstel dit vóór je planning of retries activeert.

5. Voeg pas daarna foutafhandeling toe

Make beschrijft error handlers als aparte route binnen een scenario. Leg vast welke fout veilig opnieuw mag en wanneer een beheerder moet ingrijpen. Zie ook de n8n-route voor een foutpad voor hetzelfde ontwerpprincipe.

Veelgemaakte fouten

• Planning aanzetten vóór een handmatige test. Daardoor ontstaan fouten op een groter volume.
• Dezelfde trigger niet tweemaal testen. Dan blijft dubbele uitvoer onopgemerkt.
• Een unstable tijdstempel als sleutel gebruiken. Een retry krijgt dan een nieuw record.
• Fouten laten verdwijnen zonder melding. Dan weet niemand dat een proces stil staat.
• Testen met echte klantdata. Gebruik veilige proefgegevens.

Officiële bronnen

helpcentrum en error handlers.

Wil je een Make-scenario met foutpad en overdracht laten controleren, stel je vraag via WhatsApp.

Ontwerp eerst de grens van het scenario

Een scenario is beter te testen wanneer het een klein, afgebakend contract heeft: één gebeurtenis komt binnen, een controle bepaalt of deze nieuw is en één veilige actie schrijft een testresultaat. Voeg in de eerste versie geen vertakkingen voor alle uitzonderingen, meerdere planningen of ketens van nieuwe systemen toe. Die uitbreiding kan na een geslaagde herhaaltest, niet ervoor. Beschrijf ook wat er níet mag gebeuren, bijvoorbeeld geen productiecontact aanmaken, geen factuur versturen en geen bestaande rij verwijderen.

Kies bewust tussen een geplande en een directe trigger. Een directe trigger kan dezelfde gebeurtenis opnieuw ontvangen; een geplande trigger kan een bron opnieuw lezen. In beide gevallen heeft de bestemming een stabiele bron-ID nodig om te bepalen of de gebeurtenis al verwerkt is. Een run-ID van Make of een nieuw tijdstip is niet geschikt als sleutel, want die verandert bij een nieuwe uitvoering. Lees de uitleg over unieke sleutels en mapping voordat je een opslag- of zoekstap toevoegt.

Controleer foutafhandeling vóór je planning activeert

Make kan onvoltooide uitvoeringen bewaren wanneer die instelling is ingeschakeld. Een onderbroken run kun je vervolgens beoordelen, handmatig oplossen of voor ondersteunde fouten laten herproberen. Dat is geen reden om alle foutgegevens zonder beoordeling te bewaren. Controleer welke gegevens de scenario-instellingen en logweergave opslaan; gebruik geen echte persoonsgegevens als test en pas passende privacyinstellingen toe.

Een error handler is een apart pad vanaf een module. De impact en frequentie van de fout bepalen of een fout moet stoppen, wachten op beoordeling of begrensd opnieuw proberen. Voor een pilot is een veilige stop met een melding aan de eigenaar meestal duidelijker dan een onbegrensde retry. Zet in die melding alleen scenario, module, status en tijdstip. Een foutmelding zonder ontvanger is geen herstelroute.

Voorbeeld: een teststatus naar een testtaak

Een testlijst bevat één record met vaste ID demo-01. Wanneer de status klaar wordt, moet er één testtaak bestaan met dezelfde ID. Het scenario leest het record, zoekt eerst in de testbestemming op demo-01 en maakt alleen een taak als die niet bestaat. Bij een bestaande taak werkt het scenario die hooguit bij, of het stopt zichtbaar, afhankelijk van de vooraf gekozen regel. De foutmelding noemt alleen scenario teststatus, de mislukte module en het tijdstip.

Voer nu precies dezelfde wijziging twee keer uit. Na de eerste run controleer je ID, aantal taken en status. Na de tweede run verwacht je nog steeds één taak. Is er een tweede taak, pauzeer je planning en controleer je waar de zoekstap, filter of sleutel afwijkt. Verwijder niet eerst de dubbele taak om de test groen te laten lijken. Leg de oorzaak en herstelactie vast en doe daarna de test opnieuw.

Meten, verifiëren en terugdraaien

Bij een pilot meet je alleen technische signalen: één veilige test gestart, één beoogde uitkomst, één herhaaltest en eventuele foutmelding afgeleverd. Meet geen payloadinhoud en stuur geen identificerende gegevens naar analytics. Het aantal succesvolle runs zegt ook niet dat de zakelijke regel juist is; de proceseigenaar moet de testuitkomst controleren. Pas na die controle wordt een planning met beperkte frequentie geactiveerd.

Wanneer een wijziging fout loopt, schakel je de planning uit of pauzeer je de vervolgactie, controleer je of een testresultaat gedeeltelijk is gemaakt en kies je één herstelactie. Zet een vorige versie alleen terug wanneer de eigenaar begrijpt welke mapping of voorwaarde daarmee verandert. Documenteer scenario, trigger, sleutel, testbestemming, foutpad en eigenaar in de overdrachtsroute. Heeft de bestemming al dubbele records, volg dan eerst de route voor dubbele en verkeerde data.

Veelgestelde vragen

Moet ik incomplete executions altijd inschakelen?

Niet automatisch. Beoordeel de gevolgen, privacy en opslag van de gegevensstroom. Kies een instelling pas wanneer een eigenaar weet hoe een onderbroken run wordt gecontroleerd en hersteld.

Kan ik een scenario testen met de gewone actie?

Een actietest kan echte wijzigingen maken. Gebruik daarom een testbestemming en controleer vooraf welk effect de module heeft.

Wanneer mag ik meer modules toevoegen?

Pas wanneer succes, fout en herhaling van de kleinste route aantoonbaar werken en de eigenaar begrijpt hoe die worden hersteld.