Power Automate-flow werkt niet: trigger en acties controleren (2026)

Een Power Automate-flow herstel je het snelst door één veilige run van trigger tot eerste fout te volgen. Pas niet meerdere acties tegelijk aan en probeer een mislukte run niet opnieuw voordat je dubbele uitvoer kunt uitsluiten.

Stappenplan

1. Isoleer één veilige test

Kies een testrecord zonder persoonsgegevens of financiële inhoud. Leg vast wat de trigger moet doen en waar precies één testresultaat mag landen. Heb je de workflow nog niet scherp, begin dan met de procesinventarisatie.

2. Controleer de trigger en run history

Open de run history en kijk of de trigger is gestart. Microsoft beschrijft het bekijken en herstellen van cloudflows in de officiële troubleshooting-richtlijn. Noteer alleen actienamen, status en tijdstip, geen payloads of autorisatiegegevens.

3. Zoek de eerste afwijkende actie

Een latere fout kan een gevolg zijn. Vergelijk de verwachte testuitkomst met de eerste actie die overslaat, faalt of onverwacht veel items verwerkt. Controleer daarna de verbinding, voorwaarde en datamapping van alleen die stap.

4. Test retry en dubbele runs apart

Voer niet automatisch opnieuw uit. Controleer eerst de unieke sleutel voor dubbele gegevens en test een herhaalde trigger met een veilige record. Microsoft licht retry-beleid toe bij Power Automate error handling.

5. Leg het herstel vast

Noteer welke wijziging de test herstelde, wie toegang heeft en wat je bij een volgende fout controleert. Bouw daarna een beheer- en overdrachtsroute.

Veelgemaakte fouten

• Meerdere acties tegelijk wijzigen. Je verliest het bewijs welke stap de fout herstelde.
• Volledige runinvoer delen. Daarin kunnen persoonsgegevens en secrets staan.
• Blind een run opnieuw versturen. Dat kan dubbele taken, mails of gegevens maken.
• Verbindingen met een persoonlijk account laten draaien. Dat belemmert overdracht en herstel.
• Alleen een groene status controleren. Controleer ook de juiste bestemming en precies één resultaat.

Officiële bronnen

officiële troubleshooting-richtlijn en Power Automate error handling.

Wil je dat een flow gecontroleerd wordt doorgelopen zonder gevoelige inhoud te delen, stel je vraag via WhatsApp.

Diagnose: welk symptoom zie je precies?

Maak onderscheid tussen vier situaties: de flow slaat niet op, de trigger start niet, een actie faalt, of alle stappen zijn groen maar het resultaat klopt niet. Elke situatie vraagt een andere eerste controle. Microsoft adviseert bij cloudflows om de run history te gebruiken, verbindingen en rechten te controleren en de eerste foutmelding te onderzoeken. Noteer alleen de naam van de stap, statuscode, tijdstip en omgeving. Kopieer geen invoer, uitvoer, autorisatieheader, e-mailadres of gedeelde link naar een ticket of chat.

Bij geen run controleer je de status van de flow, de gekozen omgeving en de voorwaarden van de trigger. Sommige triggers pollen in een interval: een test is dus niet per definitie direct zichtbaar. Bij een rode actie kijk je naar de eerste rode stap, niet naar alle latere gevolgen. Bij een groen resultaat vergelijk je in de testbestemming het werkelijke veld, aantal en tijdstip met het verwachte resultaat. Een groene run bewijst niet dat je mapping zakelijk juist is.

Veilige beslisvolgorde

1. Pauzeer planning of een risicovolle vervolgactie wanneer een test onjuiste mutaties maakt.
2. Kies één herkenbare testrecord zonder klant- of financiële inhoud en één testbestemming.
3. Controleer status, trigger en de eerste afwijkende stap in die ene run.
4. Herstel één instelling, bijvoorbeeld een verlopen verbinding, een voorwaarde of een veldverwijzing.
5. Test opnieuw met hetzelfde record en controleer ook dat de bestemming niet dubbel is geraakt.
6. Documenteer de wijziging en pas daarna de normale planning weer toe.

Een HTTP 401 of 403 wijst vaak op toegang of toestemming; een 400 kan betekenen dat een parameter of mapping niet past. Behandel een statuscode als aanwijzing, niet als opdracht om credentials te verzamelen. Laat de aangewezen eigenaar de verbinding in de beheeromgeving herstellen. De beheerder moet nog steeds bepalen welke rechten passend zijn.

Voorbeeld: de flow loopt, maar schrijft een lege status

Een testflow moet bij een wijziging van een veilige teststatus één item in een testlijst bijwerken. De run is groen, maar het doelveld is leeg. Controleer eerst welke bronwaarde de actie werkelijk kreeg en of de conditionele stap daarvoor heeft gelopen. Vergelijk vervolgens in een mappingtabel bronveld, verwacht type, doelveld en lege waarde. Als de bron een leeg veld mag bevatten, kies dan bewust voor stoppen, een veilige standaardwaarde of handmatige beoordeling. Vul geen willekeurige tekst in alleen om groen te krijgen.

Maak na de wijziging dezelfde teststatus opnieuw actief. Komt er precies één bijgewerkt testitem met de verwachte vaste waarde, dan is het herstel aantoonbaar. Komt er een nieuw item bij, onderzoek dan eerst dubbele runs en unieke sleutels. Is er een foutpad nodig, leg eigenaar en melding vast volgens automatisering beheren.

Foutpad, melding en herstel

Een foutpad heeft drie duidelijke uitkomsten: veilig stoppen, de minimale context vastleggen en de eigenaar attenderen. Microsoft beschrijft dat foutstatus en melding zichtbaar moeten zijn en dat een workflow na een kritieke fout kan termineren. Gebruik in een melding bijvoorbeeld alleen flownaam, stap, status, tijdstip en test of productie. Zet er geen volledige payloads, tokens of persoonsgegevens in.

Een retry is geen universele oplossing. Herhaal alleen wanneer de actie veilig idempotent is of wanneer de bestemming de bestaande gebeurtenis met een stabiele sleutel herkent. Als een actie een echte e-mail, taak, CRM-record of mutatie kan maken, controleer je eerst de bestemming. Bij twijfel blijft de flow gepauzeerd en beoordeelt de proceseigenaar het herstel. Voor een brede proceskeuze helpt de procesinventarisatie.

Veelgestelde vragen

Mag ik de fouttekst online opzoeken?

Ja, maar verwijder eerst namen, URL's, identificaties, headers en andere vertrouwelijke inhoud. Zoek bij voorkeur op een generieke foutcode en de naam van de connector.

Wie mag een verbinding opnieuw autoriseren?

Alleen de aangewezen eigenaar met passende rechten. Een ontwikkelaar of collega hoeft geen wachtwoord of token te ontvangen om de diagnose te documenteren.

Wanneer is de flow weer betrouwbaar?

Wanneer dezelfde veilige test de verwachte uitkomst geeft, de herhaaltest geen dubbele actie maakt en eigenaar plus herstelroute zijn vastgelegd.