Prompt-to-workflow

Wat is prompt-to-workflow?

Prompt-to-workflow betekent dat je een automatisering in een of twee zinnen beschrijft en de tool de flow laat samenstellen. Je typt iets als "als er een factuur binnenkomt in de boekhoudmailbox, bewaar de bijlage in SharePoint en post een bericht in het kanaal Boekhouding", en enkele seconden later staat er een flow op je scherm met een trigger, een handvol acties en de connectoren al gekozen.

Elk groot automatiseringsplatform heeft er intussen een versie van. In Power Automate heet de ingang Describe it to design it, en Microsoft documenteert dat Copilot de structuur van je flow genereert op basis van je beschrijving, met een voorgestelde trigger en een of meer acties erin. De AI Workflow Builder van n8n vertrekt van een beschrijving in gewone taal en doet zelf de nodekeuze, de plaatsing en de configuratie. Zapier heeft Copilot, die samen met jou de Zap bouwt op basis van je beschrijving en daarna verder praat over de stukken die fout zaten.

Het woord dat in alle drie de beschrijvingen het gewicht draagt, is structuur. Wat je terugkrijgt is een ontwerp met de vorm van de automatisering erin, en bijna geen van de beslissingen die er een draaiend houden.

Wat de bouwer oplevert, en wat er nog niet in zit

In de eerste versie krijg je betrouwbaar de trigger, de connectoren, de stappen in een plausibele volgorde en een deel van de parameters. De documentatie van Power Automate is eerlijk over dat laatste: de AI vult sommige parameters mogelijk niet in, ook al stonden ze in je beschrijving.

Wat ontbreekt, is net het deel dat tijd vraagt. Niemand heeft beslist wat er gebeurt als de mail twee bijlagen bevat, onder welk account de flow draait, wie hem mag aanpassen, of een mislukte stap opnieuw geprobeerd of gestopt wordt, en wie te weten komt dat het misging. Uitzonderingen, rechten, retries en de afhandeling van fouten zijn het grootste deel van het werk in elke automatisering die zonder toezicht draait, en in een gegenereerd ontwerp zit daar niets van.

De leveranciers zeggen het zelf in hun documentatie. De responsible AI FAQ van Microsoft voor Copilot in cloud flows stelt dat alle wijzigingen van Copilot in de designer nagekeken horen te worden, en dat Copilot niet in staat is om fouten in een flow op te lossen. Zapier zegt dat je je workflows grondig test voor je ze live laat draaien, om zaken als ongewilde Zap-lussen of verkeerde stappen te vermijden. Bij n8n is de derde stap, na beschrijven en bouwen, nakijken en bijstellen.

Daarom voelen de eerste negentig seconden zoveel beter aan dan de twee dagen erna. De generator is snel in het stuk dat vroeger vervelend was: de juiste trigger vinden, weten in welke connector de actie zit, die dingen aan elkaar hangen. Hij is niet snel in het stuk dat altijd al het echte project was, want dat bestaat uit zakelijke beslissingen en niemand heeft het model verteld wat jouw bedrijf beslist heeft.

Wat een beschrijving nodig heeft om een bruikbaar ontwerp te geven

Het verschil tussen een ontwerp waarop je kan verderbouwen en een ontwerp dat je weggooit, zit bijna volledig in de prompt, en meer bepaald in vier dingen die erin benoemd staan.

• De trigger. Zeg wat de flow start en hoe vaak dat gebeurt. "Als er een mail toekomt op facturen@" is een trigger. "Voor binnenkomende facturen" is er geen.

• De systemen. Noem de producten bij naam. De prompthandleiding van Microsoft vraagt je om de connector expliciet te vermelden: Outlook, Teams, Forms. Een beschrijving die "ons boekhoudpakket" zegt, levert een ontwerp op dat geraden heeft.

• De beslispunten. Zeg waar de flow splitst en op welke waarde. Boven 500 euro moet de zaakvoerder goedkeuren, daaronder niemand.

• Het foutgeval. Zeg wat er moet gebeuren als het bestand niet weggeschreven raakt of de leverancier niet in het systeem staat. Benoem het en er verschijnt tenminste een tak die je daarna kan corrigeren.

Schrijf die vier dingen op en kijk naar wat er dan staat. Het is een kleine specificatie: een gebeurtenis, de betrokken systemen, de regels en het scenario waarin het misloopt. Dat is dezelfde redenering als achter spec-driven development aan de codekant. De tool is veranderd. Het denkwerk is nergens naartoe verhuisd.

Een gegenereerde factuurflow, en de vijf dingen die iemand er nog bij deed

Een technische groothandel met veertig mensen wil leveranciersfacturen uit een gedeelde mailbox in SharePoint krijgen. De operations manager typt: "Als er een mail met een PDF-bijlage toekomt op facturen@, bewaar de bijlage in de SharePoint-bibliotheek Inkomende facturen en post een bericht in het Teams-kanaal Boekhouding."

Binnen de minuut staat het ontwerp er, met vier blokken: een trigger op nieuwe mail, een voorwaarde op het hebben van een bijlage, een actie die het bestand in de bibliotheek aanmaakt, en een actie die post in het kanaal. Iemand meldt de connecties aan, test met een mail, en het werkt. Dan gaat het live, en de volgende twee dagen komen deze vijf dingen erbij.

1. Een filter op wat als factuur telt. De trigger vuurt op elke mail in die mailbox: afwezigheidsberichten, de nieuwsbrief van de leverancier, de leveringsbon die een chauffeur gefotografeerd heeft. De gegenereerde voorwaarde kijkt enkel of er een bijlage bij zit. Iemand moest het domein van de afzender en de bestandsextensie controleren, en beslissen wat er met de rest gebeurt.

2. Een bestandsnaam die niet botst. Drie leveranciers sturen een bijlage die factuur.pdf heet, en de actie die het bestand aanmaakt faalt op de tweede, want die naam staat al in de bibliotheek. Iemand moest de naam opbouwen uit de leverancier, het factuurnummer en de datum, en beslissen wat een herhaling met het oudere bestand doet.

3. Een weg voor als het misgaat. Standaard draait een actie enkel als de stap ervoor met de status Succeeded eindigde, dus als de SharePoint-stap faalt, wordt het Teams-bericht stilzwijgend overgeslagen en eindigt de run in het rood, in een geschiedenis die niemand opent. Iemand moest de stappen in een scope groeperen, er een stap bij zetten die pas draait nadat die scope gefaald is, en die het onderwerp en de link naar de run laten posten waar een mens kijkt.

4. De identiteit waaronder de flow draait. De generator meldde de connecties aan onder het account van de persoon die de prompt getypt had. Power Automate documenteert dat een cloud flow het plan van zijn eigenaar gebruikt, en dat hij terugvalt naar het lage performanceprofiel zodra die eigenaar het bedrijf verlaat. Iemand moest de connecties naar een serviceaccount verhuizen en een tweede eigenaar toevoegen.

5. Wie de bibliotheek mag lezen. De SharePoint-site die het ontwerp koos, was de site die de operations manager toevallig openstaan had, en iedereen in het bedrijf kon daarin lezen. Leveranciersfacturen bevatten rekeningnummers en betalingstermijnen, dus iemand moest de bibliotheek verplaatsen, er rechten op zetten en nakijken of de flow er nog in mocht schrijven.

Dezelfde flow, met de hand gebouwd, bij de eerste fout

Wat een gegenereerde flow onderscheidt van een flow die iemand bewust gebouwd heeft, is wat er klaarstaat op het moment van de eerste fout.

• Wie het te weten komt, en wat die te horen krijgt. Bij het gegenereerde ontwerp staat de run als mislukt in de runhistoriek, moet iemand actief gaan kijken, en vindt die daar de foutmelding van het platform met een link. Bij de handgebouwde flow komt er een bericht in het kanaal dat de boekhouding toch al leest, met de leverancier, het factuurnummer en de stap die stukging erin.

• Wat de rest van de flow doet. Het gegenereerde ontwerp slaat elke stap na de mislukte over, want standaard draait een stap enkel na succes, dus ook het Teams-bericht gaat niet buiten. De handgebouwde flow draait zijn catch-tak en verplaatst de factuur naar een uitzonderingsmap.

• Wat er gebeurt als niemand het merkt. Power Automate zet een flow af na 14 dagen aanhoudende fouten, dus het gegenereerde ontwerp valt vanzelf stil en de facturen blijven ongelezen in de mailbox liggen. Bij de handgebouwde flow herhaalt de melding zich en groeit de wachtrij waar mensen ze zien.

Onder dat alles zitten de retries. Power Automate legt op connectoracties een standaard retrybeleid: tot twaalf nieuwe pogingen met exponentieel groeiende tussenpozen op het medium en high performanceprofiel, en tot twee op het lage profiel. Die pogingen gaan enkel af bij tijdelijke fouten: timeouts, throttling en serverfouten. Een vervallen token komt terug als een authenticatiefout en wordt helemaal niet opnieuw geprobeerd, en een dubbele bestandsnaam is evenmin tijdelijk. Welke fouten een nieuwe poging verdienen, welke een stop en welke een mens, is een zakelijke keuze die de generator nooit maakt.

Wie het proces kent, kan het nu zelf bouwen

Dit is het stuk dat echt nieuw is. De magazijnverantwoordelijke die weet dat de leveringsbon eerst tegen de factuur moet, kan nu zelf iets maken dat draait, dezelfde namiddag dat de ergernis opkwam. Dat is de winst die een citizen developer al haalde uit een low-codeplatform, alleen komt ze nu vroeger in het traject.

De kloof zit erin dat een proces kennen en software draaiend houden twee verschillende vaardigheden zijn. Hij weet precies welke facturen een tweede handtekening nodig hebben. Hij weet niet noodzakelijk dat een connectie een bewaarde credential is met een vervaldatum, dat de flow stopt op de dag dat dat token verloopt, of dat dezelfde mail die twee keer binnenkomt de factuur ook twee keer inboekt. Dat is geen verwijt aan hem. Het beschrijft wat zo'n bouwer aflevert: de zichtbare logica, zonder het operationele contract eronder.

Wat je best regelt voor je het breed openzet

Een bedrijf kan op deze manier in een kwartaal van vijf naar vijftig automatiseringen gaan. Niet uit roekeloosheid, gewoon omdat het makkelijk is. Vijftig automatiseringen zonder inventaris, zonder eigenaars met naam en zonder foutafhandeling: dat is shadow IT op hoge snelheid, gebouwd met goedgekeurde tools binnen de goedgekeurde tenant, en net dat maakt het moeilijk op te merken. In Power Platform staat de functie standaard aan in de ondersteunde regio's, en uitzetten loopt via Microsoft-support, dus verbieden is evenmin de goedkope weg. Vier dingen halen er de scherpe kantjes af.

1. Een omgeving waar bouwen mag. In Power Platform is environment routing een instelling op tenantniveau, standaard uit, die makers naar hun eigen developer-omgeving stuurt in plaats van naar de gedeelde standaardomgeving. Zet ze aan en experimenten belanden niet meer in de omgeving waar iedereen op steunt. Connectorbeleid bepaalt daarna welke connectoren samen in een flow mogen, en een flow die daartegen ingaat, wordt opgeschort in plaats van verder te draaien.

2. Een eigenaar per flow, op papier. Niet de maker bij toeval, maar een eigenaar met opzet, plus iemand die kan overnemen. Dit is het goedkoopste van de vier en het wordt het vaakst overgeslagen, want op de dag dat je iets bouwt voelt die vraag nog theoretisch aan.

3. Een gedeelde foutmailbox of een kanaal dat echt gelezen wordt. Een plek waar de fouten van alle automatiseringen samenkomen, opgevolgd zoals de algemene mailbox opgevolgd wordt. Een foutmelding die enkel bij de bouwer terechtkomt, werkt niet meer vanaf de dag dat die op verlof gaat.

4. Een leesregel voor alles wat aan geld of klantgegevens raakt. Betalingen, creditnota's, prijzen, persoonsgegevens, alles wat een klant te zien krijgt: iemand anders kijkt ernaar voor het aan gaat. Zapier heeft dat in zijn Enterprise-plan als publishing restrictions, waarbij iemand goedkeuring moet vragen aan een super admin of de accounteigenaar voor een Zap live gaat. Heeft jouw platform daar geen functie voor, dan werkt de regel prima als afspraak.

Waar moet je op letten bij prompt-to-workflow

Een gegenereerde flow moet nog altijd nagelezen worden, en een flow leest lastiger dan code. Wie een pull request opent, ziet de logica in een kolom tekst staan en kan erin zoeken. Wie een flow opent, ziet een schema, moet elke actie openklappen, en vindt het run-after-gedrag en het retrybeleid telkens nog twee klikken dieper. Dat nalezen is niet optioneel en het duurt langer dan mensen verwachten.

Preview is niet hetzelfde als af. Describe it to design it in Power Automate staat nog altijd als preview, ondersteunt enkel beschrijvingen in het Engels, en werkt voor cloud flows en een deel van de connectoren. De helpdocumentatie van Zapier noemt Copilot een open beta. De Copilot in de cloud flow designer draagt geen preview-label. Kijk na waar je precies op steunt voor je er een uitrol rond plant.

Gebruik het als prototype, niet als oplevering. Voor een kleiner bedrijf is dit een uitstekende manier om te weten te komen of een flow de moeite waard is. Beschrijf hem, bekijk het ontwerp, laat hem een keer met de hand lopen, en je weet in tien minuten waar een specificatievergadering twee weken over discussieert. Bouw daarna de versie die het moet uithouden: de uitzonderingsweg, de eigenaar, de rechten, de melding. Het ontwerp deed het goedkope denkwerk over connectoren en triggers, en geen enkel denkwerk over maandagochtend.