Leer hoe je een interne goedkeurings-webapp bouwt zonder aangepaste code: breng stappen in kaart, ontwerp formulieren, stel rollen in, automatiseer routering, voeg audittrails toe en lanceer veilig.
Een interne goedkeuringswebapp is een systeem om een verzoek van “iemand heeft iets nodig” naar “er is een beslissing genomen—en we kunnen het later bewijzen” te brengen. De beste systemen doen een paar kernzaken consequent, zelfs als het precieze proces per team varieert.
De meeste interne goedkeuringsflows bevatten:
Je ziet hetzelfde patroon in veel processen:
No-code tools zijn vaak een goede keuze omdat ze teams snel laten opleveren, wekelijks te laten itereren en de eigendom bij de mensen die het proces runnen te houden. Je kunt formulieren, routeringsregels, meldingen en dashboards bouwen zonder te wachten op een traditionele ontwikkelwachtrij.
Schakel engineers in bij randgevallen zoals sterk conditionele routering (veel takken), strikte dataresidency-eisen, aangepaste SSO-constraints, of complexe integraties die middleware en robuuste foutafhandeling vereisen. In veel organisaties kan no-code nog steeds de UI afhandelen terwijl engineering de gaten opvult.
Als je iets dichter bij “op maat” wilt zonder je te committeren aan een volledige build, kan een vibe-coding platform zoals Koder.ai tussenop zitten: je beschrijft de workflow in chat en het genereert de app (meestal React aan de frontend, Go + PostgreSQL aan de backend) met opties zoals broncode-export, deployment/hosting, snapshots en rollback—handig wanneer je goedkeuringsproces eenvoudig begint maar in de tijd moet verzwaren.
Voordat je een builder opent, kies één interne goedkeuringsworkflow om eerst aan te pakken. Het doel is snel waarde te bewijzen en hetzelfde patroon daarna voor andere goedkeuringen te hergebruiken.
Een goede eerste kandidaat heeft meestal:
Voorbeelden: aankoopverzoeken onder een drempel, verlofgoedkeuringen, content/legal review voor een specifieke template, of basisleveranciersintroductie.
Wees specifiek over wat “indienen” betekent in je formulier-naar-goedkeuring proces:
Als goedkeurders routinematig om hetzelfde ontbrekende detail vragen, maak het verplicht in v1.
Schrijf elke persoon (of rol) op die betrokken is en waar beslissingen plaatsvinden: reviewers, approvers, finance, legal, en eventuele gedelegeerden tijdens vakanties. Noteer ook “rand”-beslissingen zoals “terugsturen voor aanpassingen” of “meer info vragen”, want die veroorzaken de meeste opvolgingen.
Kies 2–3 meetbare uitkomsten:
Met een gedefinieerde start, finish en succesmetingen worden de overige keuzes in workflowautomatisering veel eenvoudiger.
Voordat je een builder aanraakt, teken het goedkeuringspad op één pagina. Dit voorkomt “werkt bijna”-workflows—waar aanvragen vastlopen, naar de verkeerde persoon gaan of rondstuiteren zonder duidelijk einde.
Begin met een simpele ruggengraat die je hardop kunt voorlezen:
Submit → Review → Approve/Reject → Close
Noem voor elke stap wie het doet (rol of team), wat ze moeten zien en wat ze kunnen beslissen. Als je een stap niet in één zin kunt beschrijven, verbergt die vaak meerdere acties die gescheiden moeten worden.
Maak duidelijk of reviews plaatsvinden:
Parallelle flows hebben een regel nodig voor "klaar": allen moeten goedkeuren, ieder individueel kan goedkeuren, of meerderheid. Kies dit nu—later veranderen dwingt vaak een herbouw af.
Een afwijzing kan betekenen:
Kies wat juist is voor compliance en rapportage. "Bewerk en dien opnieuw" is gebruikelijk, maar registreer altijd de oorspronkelijke beslissing.
Breng de niet-gelukkige paden van tevoren in kaart:
Als je deze op papier vastlegt, wordt bouwen configuratie in plaats van giswerk.
Een no-code goedkeuringsapp werkt het beste als het datamodel simpel, consistent en makkelijk te rapporteren is. Voordat je schermen bouwt, bepaal welke records je opslaat en hoe ze met elkaar verbonden zijn.
Voor de meeste interne goedkeuringsworkflows dekt een paar tabellen (of collecties) 90% van de behoeften:
Houd Request als de enige bron van waarheid. Alles anders verwijst ernaar.
Definieer de must-have velden die nodig zijn om te routeren en te beslissen. Typische verplichte velden zijn:
Alles anders kan optioneel beginnen. Je kunt later velden toevoegen als goedkeurders daadwerkelijk naar iets blijven vragen.
Bepaal vooraf welke documenten bewaard moeten worden (offertes, contracten, screenshots) en hoe lang.
Gebruik een klein, duidelijk set statussen zodat iedereen voortgang op dezelfde manier interpreteert:
Draft → Submitted → In Review → Approved / Rejected → Completed
Vermijd te veel custom statussen vroeg. Een consistent statusveld maakt filteren, herinneringen en rapportage veel eenvoudiger.
Een goede goedkeuringsapp slaagt of faalt op bruikbaarheid. Als mensen tegenzin hebben om een verzoek in te dienen of niet kunnen zien wat de volgende stap is, vallen ze terug op e-mail.
De meeste interne goedkeuringsworkflows zijn af te handelen met een klein aantal pagina's:
Houd de navigatie simpel: "Nieuwe aanvraag", "Mijn aanvragen", "Moet ik goedkeuren" en "Instellingen" (voor admins).
Begin met de minimaal verplichte velden en gebruik conditionele velden om het formulier kort te houden. Bijvoorbeeld: toon alleen "Leveranciersgegevens" als "Aankooptype = Nieuwe leverancier", of toon "Reden voor uitzondering" alleen als een beleidscheckbox niet is aangevinkt.
Hierin blinken no-code tools uit: je kunt secties tonen/verbergen op basis van dropdowns, bedragen of afdeling—zonder aparte formulieren te maken.
Toon op elk record:
Een eenvoudige voortgangsindicator plus een regel "Wacht op: \u003cnaam/rol\u003e" voorkomt de meeste "Updates?"-berichten.
Voeg korte toelichting en voorbeelden onder lastige velden toe ("Voeg de ondertekende offerte toe (PDF)", "Gebruik kostenplaats zoals 4102-Operations"). Gebruik validatie om vermijdbare herwerking te voorkomen: verplichte bijlagen voor bepaalde aanvraagtypes, toegestane bereiken voor bedragen en duidelijke foutmeldingen.
Het doel is minder verduidelijkende vragen, snellere beslissingen en schonere records voor rapportage.
Als je goedkeuringsapp een gebouw is, dan zijn rollen en permissies de sloten en sleutels. Routeringsregels zijn de bewegwijzering die ervoor zorgt dat elk verzoek op het juiste bureau terechtkomt—zonder handmatig najagen.
Begin met een klein aantal rollen die je hergebruikt:
Schrijf in eenvoudige taal op wat elke rol kan doen voordat je de builder raakt.
Goedkeuringen mislukken als iedereen alles kan zien of bewerken. Definieer permissies per fase:
Een praktische standaard: vergrendel sleutelvelden na indiening (bedrag, leverancier, datums) en sta bewerkingen alleen toe via een "terugsturen"-actie.
Hard-coded namen schalen niet. Geef de voorkeur aan routeringsregels zoals:
Dit houdt de workflow accuraat wanneer mensen komen, gaan of van team wisselen.
Goedkeuringen lopen vaak vast door vakanties en overvolle inboxen. Voeg toe:
Deze regels beschermen doorvoer zonder controle te verliezen.
Automatisering verandert een simpel formulier in een betrouwbare interne goedkeuringsworkflow. Het doel is eenvoudig: wanneer een verzoek van status verandert, krijgt de volgende persoon meteen de juiste taak—zonder handmatig najagen of kopiëren/plakken van links.
Stel regels in zoals: Draft → Submitted → Manager Review → Finance Review → Approved/Rejected. Elke statuswijziging moet automatisch:
Houd routeringsregels leesbaar. Als je uitzonderingen nodig hebt (bijv. "Als bedrag \u003e $5.000, voeg CFO-goedkeuring toe"), definieer ze als duidelijke voorwaarden gekoppeld aan data-velden.
Stuur minimaal twee soorten berichten:
Gebruik de kanalen die je organisatie al controleert—e-mail plus Slack/Teams indien beschikbaar. Houd berichten kort en consistent zodat ze geen ruis worden.
Goedkeuringen lopen vast wanneer niemand verantwoordelijk is voor tijd. Voeg toe:
Maak escalaties voorspelbaar (en zichtbaar) zodat goedkeurders vertrouwen in het systeem krijgen.
Automatisering moet ook veelvoorkomende fouten stoppen:
Deze beveiligingen verminderen herwerk en zorgen dat elk verzoek hetzelfde pad volgt.
Een goedkeuringsapp werkt pas als iedereen kan zien wat wacht, wat vastzit en wat klaar is—zonder rond te vragen. Dashboards maken van "Waar is dit verzoek?" een selfservicevraag.
Maak één plek waarop reviewers dagelijks vertrouwen. Je inboxweergave moet bevatten:
Houd elke rij actiegericht: aanvrager, afdeling, bedrag/type, ingediendatum, vervaldatum en één-klik goedkeuren/afwijzen.
De meeste opvolgvraagstukken zijn voorspelbaar: "Toon alle openstaande verzoeken van Sales deze maand" of "Vind de PO die ik afgelopen dinsdag heb ingediend." Bouw filters voor:
Als je tool het ondersteunt, voeg opgeslagen weergaven toe zoals "Openstaand team" of "Finance wachtrij."
Dashboards hoeven niet elk veld te tonen om nuttig te zijn. Richt je op operationele metrics:
Gebruik geaggregeerde aantallen en duur zodat leiders trage stappen zien zonder vertrouwelijke inhoud te onthullen.
Ook al gebruik je nog geen BI-tool, maak rapportage eenvoudig:
Dit vermindert ad-hoc verzoeken en helpt te bewijzen dat het workflow verbetert over tijd.
Als goedkeuringen uitgaven, risico of klantafspraken beïnvloeden, heb je bewijs nodig—niet alleen "Goedgekeurd" als eindstatus. Governance is het gemakkelijkst (en goedkoopst) toe te voegen tijdens het ontwerpen van de workflow, niet nadat mensen er al op vertrouwen.
Je app moet een duidelijke geschiedenis bijhouden van wie wat deed en wanneer. Ten minste log:
Maak de auditlog zichtbaar voor admins en reviewers, maar maak het niet standaard voor iedereen zichtbaar.
Goedkeuringen zonder context zorgen later voor verwarring. Voeg een optionele opmerking bij goedkeuring toe en een verplichte "reden voor afwijzing". Dit voorkomt vage "Afgewezen"-uitkomsten en versnelt herindiening omdat de aanvrager weet wat te repareren.
Een praktisch patroon:
Gebruik least-privilege zodat mensen alleen zien wat ze nodig hebben:
Als je tool rij-niveau permissies ondersteunt, gebruik die. Zo niet, splits gevoelige workflows in aparte apps.
Bepaal vroeg hoe lang je records bewaart (bijv. 1–7 jaar afhankelijk van beleid), hoe verwijdering werkt (soft-delete is vaak veiliger) en wie kwartaalgewijs toegang controleert. Documenteer deze regels in een korte interne pagina en vermeld die vanuit de app (bijvoorbeeld: /policies/approvals).
Goedkeuringsflows staan zelden op zichzelf. De snelste weg naar adoptie is je app te koppelen aan de systemen die mensen al gebruiken: inloggen, HR-data, finance records, ticketing queues en messaging.
Als je bedrijf al Google Workspace, Microsoft Entra ID (Azure AD), Okta of soortgelijke gebruikt, zet SSO aan zodat medewerkers geen nieuw wachtwoord hoeven.
Naast gemak helpt SSO bij toegang: je kunt groepen (bijv. "Finance", "People Ops", "IT") mappen naar rollen in je goedkeuringsapp, minder handmatig beheer en minder risico dat de verkeerde persoon gevoelige verzoeken ziet.
De meeste aanvragen hebben referentiedata nodig:
Gebruik native connectors waar mogelijk zodat formulieren velden kunnen autofillen en routeringsregels betere beslissingen kunnen nemen (bijv. routeren op afdeling of bestedingsdrempel).
Als je tool geen ingebouwde integratie heeft, kun je nog steeds verbinden zonder een volledige custom app te bouwen. Veel platformen laten je:
Houd de payload simpel: request ID, aanvrager, beslissing, tijdstempel en de sleutelvelden die het doelsysteem nodig heeft.
Integraties falen—tokens verlopen, API's rate-limiten, velden veranderen. Bouw in:
Dit voorkomt "goedgekeurd maar nooit uitgevoerd"-situaties die snel vertrouwen ondermijnen.
Het testen van een interne goedkeuringsworkflow is meer dan "werkt de knop?" Het is of echte mensen echte verzoeken van begin tot eind kunnen brengen zonder verwarring of omwegen.
Maak een set realistische verzoeken en laat ze door het volledige proces lopen:
Let op knelpunten: onduidelijke velden, ontbrekende context voor goedkeurders en stappen die mensen terug naar e-mail of chat dwingen.
Begin met een kleine groep—één team of één type aanvraag—en houd de pilot lang genoeg om randgevallen te raken (gewoonlijk 2–4 weken). Plan een korte wekelijkse check-in en verzamel feedback op één plek (een formulier of gedeeld document). Prioriteer fixes die heen-en-weer verminderen: helderheid van velden, routeringsregels en timing van notificaties.
Houd documentatie kort en praktisch:
Publiceer het waar gebruikers al komen (bijv. een interne pagina zoals /help/approvals).
Breid uit per groep. Gebruik vroege metrics—doorlooptijd, afwijzingsredenen, tijd besteed per stap—om regels en formuliervelden te verfijnen. Kleine iteraties (wekelijks of tweewekelijks) houden het vertrouwen hoog en voorkomen dat de workflow een omweg wordt.
Zelfs met no-code tools raken goedkeuringsflows rommelig zonder een paar vangrails. Dit zijn faalpatronen die teams vaak vertragen—en praktische manieren om ze te voorkomen.
De neiging is om elk detail vast te leggen "voor het geval dat". Het resultaat is een formulier dat niemand wil invullen en een approval pad dat moeilijk te onderhouden is.
Begin simpel: minimale velden om een beslissing te nemen en het kortste approval pad dat nog voldoet aan beleid. Lanceer, kijk waar mensen vastlopen en voeg alleen toe wat echt nodig blijkt.
Routeringsregels, lijst met approvers en rolgebaseerde toegang hebben een duidelijke eigenaar nodig. Als niemand de workflow bezit, stapelen uitzonderingen zich op, wordt toegang verouderd en raken goedkeuringen geblokkeerd bij rolwisselingen.
Wijs een benoemde process-eigenaar toe (en een backup). Zet regelwijzigingen achter een lichtgewicht change-proces (ook een korte checklist) en plan maandelijkse reviews van approver-groepen en permissies.
Als aanvragers geen status of volgende goedkeurder zien, gaan ze mensen handmatig achtervolgen—dan faalt de automatisering.
Voeg een statuspagina toe met: huidige fase, laatst bijgewerkt tijdstip, volgende goedkeurder (of team) en een geschatte SLA. Voeg een eenvoudig dashboard toe zodat managers knelpunten zien.
Echte workflows hebben randgevallen: urgente verzoeken, afwezige goedkeurders of beleidsuitzonderingen.
Bouw veilige exception-handling: een "urgent"-vlag die een gedefinieerd snel pad activeert, delegatieregels en een gecontroleerde override die een reden vereist en in de audittrail wordt vastgelegd.
Als je verwacht dat de workflowlogica vaak verandert (nieuwe drempels, extra goedkeurders of nieuwe aanvraagtypes), overweeg dan een aanpak die makkelijk te itereren is zonder governance te verliezen. Teams gebruiken bijvoorbeeld Koder.ai om intern workflow-apps snel te genereren en te evolueren vanuit een chat-spec, met de optie om broncode te exporteren en strengere controles af te dwingen naarmate het proces volwassen wordt.
Begin met één workflow die veel pijn oplevert maar weinig complexiteit heeft:
Voorbeelden: aankoopverzoeken onder een drempel, verlofgoedkeuringen, of een basisstroom voor toegangsverzoeken. Bewijs de waarde en hergebruik hetzelfde patroon voor andere goedkeuringen.
Leg de minimale gegevens vast die nodig zijn om te routeren en te beslissen. Veelvoorkomende verplichte velden:
Als goedkeurders herhaaldelijk om een detail vragen (zoals leverancier of offerte), maak dat dan verplicht in v1.
De meeste apps hebben maar een paar kernschermen nodig:
Houd de navigatie simpel zodat gebruikers betrouwbaar "Nieuwe aanvraag", "Mijn aanvragen" en "Moet ik goedkeuren" kunnen vinden.
Gebruik een klein, gestandaardiseerd setje statussen zodat filteren, herinneringen en rapportage eenvoudig blijven:
Als je meer detail nodig hebt, laat dan het huidige stap-veld zien (bijv. “Manager review”) in plaats van veel extra statussen te maken.
Kies op basis van of volgorde belangrijker is dan snelheid:
Voor parallelle reviews, definieer vroegtijdig de voltooiingsregel: allen moeten goedkeuren, , of —dit later aanpassen veroorzaakt vaak extra werk.
Bepaal wat “afgewezen” betekent voor jouw proces:
Zelfs bij bewerk/ opnieuw indienen, bewaar je een auditrecord van de oorspronkelijke beslissing en de afwijzingsreden.
Definieer rollen en rechten per fase:
Een praktisch vangnet: vergrendel sleutelvelden (bedrag/leverancier/datums) zodra het is ingediend en sta wijzigingen alleen toe via een "terugsturen"-actie.
Gebruik organisatiegebaseerde regels in plaats van vaste namen:
Dit houdt routering accuraat wanneer mensen van rol of team veranderen.
Voeg vanaf het begin regels toe om stilstand te voorkomen:
Maak escalatiegedrag zichtbaar en consistent zodat het systeem voorspelbaar aanvoelt.
Leg genoeg vast om te beantwoorden "wie deed wat, wanneer en waarom":
Stel ook bewaartermijnen vroeg vast (bijv. 12–24 maanden voor operationele aanvragen, langer voor finance/legal) en gebruik het principe van minste privileges zodat gebruikers alleen zien wat ze nodig hebben.
