Drempelgebaseerde routering laat teams goedkeuringsregels in tabellen opslaan op basis van bedrag, afdeling of regio, zodat beleidswijzigingen geen codewijzigingen vereisen.
Hard-gecodeerde goedkeuringsregels lijken in het begin prima. Een ontwikkelaar voegt een paar voorwaarden toe, de workflow draait en het team gaat door.
Het probleem verschijnt wanneer het bedrijf verandert. Financiën verhoogt een bestedingslimiet, een regio krijgt een andere regeling, of een afdeling heeft een extra goedkeurder nodig voor bepaalde verzoeken. Wat een kleine update leek, betekent nu het aanpassen van app-logica, testen en wachten op een release.
Die vertraging is kostbaar. Een beleidswijziging die minuten zou moeten duren, kan dagen kosten wanneer er technisch werk voor nodig is. In die periode volgen medewerkers de oude regels, lopen goedkeuringen vast en beginnen managers uitzonderingen via e-mail of chat af te handelen.
Verborgen uitzonderingen maken het erger. In de loop van de tijd voegen teams ad-hoc regels toe zoals "als bedrag boven 5.000 en afdeling is Sales, stuur naar Directeur A" of "als het verzoek uit Europa komt, sla deze stap over." Wanneer die regels diep in de workflow leven, kunnen maar een paar mensen ze zien.
Dan worden eenvoudige vragen moeilijk te beantwoorden:
Als niemand het volledige regelbestand kan zien, volgen fouten. Iemand denkt dat die volgens beleid handelt, maar de app gebruikt nog een oude regel. Een nieuwe manager krijgt verzoeken die hij nooit zou mogen zien, terwijl de echte goedkeurder buiten beeld blijft.
Daarom werkt drempelgebaseerde routering beter wanneer goedkeuringsbeleid vaak verandert. In plaats van regels als vaste onderdelen van de app te behandelen, sla je ze op als bedrijfsdata die bekeken en bijgewerkt kan worden.
Stel je een eenvoudig onkostenbeleid voor. Verzoeken onder 1.000 gaan naar een teamleider, verzoeken van 1.000 tot 10.000 naar een afdelingshoofd, en alles daarboven naar Financiën. Als die limieten volgende maand veranderen, zou het bedrijf geen ontwikkelaar moeten nodig hebben om de goedkeuringen door te laten gaan.
Hard-coderen verandert gewone beleidsupdates in softwareprojecten. Dat is de echte kostenpost.
Drempelgebaseerde routering betekent dat het goedkeuringspad verandert op basis van waarden die je van tevoren definieert. Een drempel is simpelweg een grens, zoals een bedrag boven $1.000, een verzoek van de afdeling Financiën of een aankoop in Europa.
In plaats van die regels direct in de app te schrijven, sla je ze op in tabellen. De workflow leest de tabel, vindt de bijpassende regel en stuurt het verzoek naar de juiste persoon.
Een basisopzet kan er zo uitzien:
Het proces blijft hetzelfde, maar de waarden die het sturen kunnen veranderen.
Dit is het kernidee. Logica is het deel dat zegt: "controleer de regels en kies de eerste match." Beleidsdata is de lijst met regels zelf: bedragranges, afdelingen, regio's, goedkeurders en prioriteit.
Wanneer logica en beleid door elkaar lopen, kan zelfs een kleine wijziging een ontwikkelaar nodig maken om de workflow aan te passen. Wanneer ze gescheiden zijn, blijft de workflow stabiel en veranderen alleen de regelrijen.
Bijvoorbeeld: als Sales in APAC nu directeursgoedkeuring nodig heeft boven $3.000 in plaats van $5.000, update je één tabelrij. Je bouwt het hele goedkeuringsproces niet opnieuw op.
Dat is makkelijker te beheren omdat beleid vaker verandert dan de processtructuur. Teams reorganiseren, budgetten verschuiven en regio's krijgen nieuwe eigenaren. Een tabel kan dat beter aan dan hard-gecodeerde voorwaarden.
In een no-code platform zoals AppMaster betekent dat meestal het aanmaken van een regeltabel en het laten controleren van die tabel tijdens runtime door het bedrijfsproces. Het model is makkelijk te begrijpen voor niet-technische teams omdat het overeenkomt met hoe beleid in de praktijk wordt geschreven: als deze voorwaarde klopt, stuur het hierheen.
Een goede regeltabel zou één eenvoudige vraag moeten beantwoorden: wanneer een verzoek aan deze voorwaarden voldoet, wie moet het dan goedkeuren?
Als routering afhankelijk is van waarden die in code verborgen zitten, verandert elke beleidswijziging in een herbouw. Een tabel houdt die wijzigingen zichtbaar en makkelijker te beheren.
Een praktische regeltabel begint meestal met velden die het verzoek beschrijven:
Bedrag en valuta zijn belangrijk omdat hetzelfde getal in verschillende budgetten of landen iets anders kan betekenen. Een verzoek van 5.000 USD kan een andere route volgen dan 5.000 EUR of 500.000 JPY.
Afdeling en regio weerspiegelen hoe bedrijven echt werken. Financiën, HR en Operaties hebben vaak verschillende goedkeuringspaden, zelfs voor dezelfde besteding. Regio is ook van belang wanneer lokale regels of managers verschillen.
Verzoektype is een andere nuttige filter. Reizen, softwareaankopen, leveranciersbetalingen en kortingstoekenningen kunnen verschillende beoordelaars nodig hebben. Zonder dat veld kunnen niet-gerelateerde verzoeken dezelfde regel gebruiken.
Sla voor de goedkeurder een rol op in plaats van een persoonsnaam. Gebruik waarden zoals Afdelingsmanager, Regionaal Directeur of Finance Controller. Wanneer iemand van functie verandert, werk je de roltoewijzing één keer bij in plaats van elke regel te moeten aanpassen.
Het helpt ook om start- en einddatums toe te voegen. Dat dekt beleidsregels die op een bepaalde dag ingaan, tijdelijke regels tijdens budgetperiodes of geplande wijzigingen voor het volgende kwartaal. Je behoudt geschiedenis zonder verlopen regels actief te laten blijven.
Een prioriteitsveld is ook de moeite waard. Een regel voor "EU + Financiën + boven 10.000" zou meestal winnen van een ruimere regel zoals "alle afdelingen + boven 10.000." Duidelijke prioriteit houdt routering voorspelbaar.
Houd de structuur simpel: één rij moet gelijkstaan aan één goedkeuringsregel.
Als marketingkosten boven $2.000 in Europa een regionale manager nodig hebben, hoort dat in één record. Als elke rij één duidelijke betekenis heeft, is de opzet makkelijker bij te werken, te testen en te auditen.
De hoofdtabel moet zich op twee dingen richten: de voorwaarden die een regel activeren en het resultaat dat de workflow vertelt wat de volgende stap is. Dat houdt het leesbaar voor zowel zakelijke gebruikers als degene die het proces bouwt.
Een schone tabel bevat vaak deze velden:
Voor voorwaardekolommen: gebruik waar mogelijk exacte velden in plaats van vrije tekst. Een afdeling-ID is veiliger dan elke keer "Financiën" handmatig typen. Hetzelfde geldt voor regiocodes, verzoektypes en kostenplaatsen. Kleine lookup-tabellen voor afdelingen, regio's en goedkeurdersrollen helpen spelfouten te vermijden en maken filteren eenvoudiger.
Voor resultaatkolommen: bepaal wat de workflow moet teruggeven. In sommige teams moet de regel naar een specifieke persoon wijzen. In andere gevallen moet het naar een rol routeren, zoals Regionaal Manager of Finance Director. Kies één aanpak en blijf daar consistent in.
Prioriteit is belangrijk omdat meer dan één regel op hetzelfde verzoek kan matchen. Vertrouw niet op volgorde van rijen of aanmaakdatum. Voeg een numeriek prioriteitsveld toe en definieer hoe het werkt, bijvoorbeeld 1 controleert eerst en 100 later.
Je hebt ook een fallback-regel nodig. Dit is het vangnet voor alles wat niet door een specifieke rij wordt gedekt. Een standaardregel kan niet-overeenkomende verzoeken naar een operationsmanager of een admin-reviewwachtrij sturen. Zonder fallback kunnen verzoeken vastlopen zonder route.
Als je dit in AppMaster bouwt, kunnen deze tabellen visueel worden aangepast, zodat beleidswijzigingen in data gebeuren in plaats van in hard-gecodede workflow-vertakkingen.
Begin met de beslissing, niet met de tabel. Schrijf exact op welke vragen je workflow moet beantwoorden. Heeft een aankoop boven $5.000 een manager nodig? Controleert Financiën alles van Sales? Volgen verzoeken uit een regio een ander pad?
Als die keuzes duidelijk zijn, wordt drempelgebaseerde routering veel eenvoudiger omdat je beleid opslaat in plaats van later te moeten raden naar de logica.
Een eenvoudige opzet volgt meestal vijf stappen.
Eerst: maak een tabel voor goedkeuringsregels met de velden die routering beïnvloeden. Veelvoorkomende kolommen zijn amount_min, amount_max, afdeling, regio, approver_role, priority en active_status.
Tweede: bepaal welke velden leeg mogen blijven. Een lege afdeling of regio kan betekenen "deze regel geldt voor iedereen" wanneer er geen specifiekere match bestaat.
Derde: voeg regels toe van meest specifiek naar meest algemeen. Een regel voor "Sales + Europa + boven 10.000" moet gecontroleerd worden voordat een brede regel zoals "elke afdeling + elke regio + boven 10.000."
Vierde: test met echte voorbeelden vóór lancering. Gebruik randgevallen zoals precies $5.000, ontbrekende afdelinggegevens of een regio zonder aangepaste regel.
Vijfde: beperk wie de tabel mag bewerken. Beleidswijzigingen moeten eenvoudig zijn, maar niet voor iedereen openstaan.
Hier is een eenvoudig voorbeeld. Een verzoek van $12.000 van HR in Noord-Amerika kan eerst matchen op een regel "HR boven 10.000," die het naar de HR-directeur stuurt. Als er geen HR-specifieke regel bestaat, kan het systeem terugvallen op een ruimere regel zoals "elke afdeling boven 10.000," die het naar Financiën stuurt.
Volgorde doet er meer toe dan veel teams verwachten. Als brede regels bovenaan staan, krijgt de verkeerde persoon het verzoek en verliest men het vertrouwen in het systeem.
Voordat je live gaat: wijs één eigenaar aan voor regelwijzigingen, houd een kort beleidsdocument bij en test opnieuw na elke update. Kleine routeringswijzigingen kunnen grote effecten hebben.
Stel je een bedrijf voor dat één inkoopformulier gebruikt voor alle teams. Elk verzoek bevat een bedrag, een afdeling en een regio. Het systeem controleert die waarden tegen een regeltabel en kiest de juiste goedkeurder.
Stel dat het bedrijf twee afdelingen heeft: Marketing en IT. Beide kunnen een verzoek van $4.000 indienen, maar het goedkeuringspad hoeft niet hetzelfde te zijn.
| Afdeling | Regio | Bedrag-range | Goedkeurder |
|---|---|---|---|
| Marketing | US | $0 tot $5.000 | Marketingmanager |
| Marketing | US | $5.001+ | Financieel Directeur |
| IT | US | $0 tot $3.000 | IT-manager |
| IT | US | $3.001+ | CTO |
| Marketing | EU | $0 tot $5.000 | Regionale Marketingleider |
Vergelijk nu twee verzoeken met hetzelfde bedrag. Een marketingverzoek van $4.000 in de VS gaat naar de Marketingmanager. Een IT-verzoek van $4.000 in de VS slaat de IT-manager over en gaat naar de CTO, omdat IT een lagere drempel heeft.
Regio kan het resultaat ook veranderen. Een Marketingverzoek van $2.500 in de VS gaat naar de Marketingmanager, maar hetzelfde verzoek in de EU gaat naar de Regionale Marketingleider. Het formulier blijft hetzelfde. Alleen de matchende regel verandert.
Dat is de echte waarde van een regeltabel. Beleid staat in data, niet in workflowlogica.
Als het bedrijf volgende maand zijn beleid bijwerkt, hoef je niet het hele proces opnieuw op te bouwen. Als IT besluit dat verzoeken boven $2.000 nu naar de CTO moeten, bewerk je slechts één rij:
Alles blijft verder werken. Nieuwe verzoeken volgen het nieuwe beleid meteen terwijl de app-structuur onaangeroerd blijft.
Het moeilijkste aan drempelgebaseerde routering is meestal niet het kernidee. Het zijn de rommelige randgevallen die later opduiken, wanneer beleid verandert en niemand zich herinnert waarom een verzoek naar de verkeerde persoon ging.
Een veelgemaakte fout is overlappende regels zonder duidelijke prioriteit. Je kunt een regel hebben die alle Marketingverzoeken boven $3.000 naar het afdelingshoofd stuurt en een andere die ieder verzoek boven $5.000 naar Financiën stuurt. Een Marketingverzoek van $6.000 matcht beide, dus het systeem heeft een duidelijke winnaar nodig. Zet die prioriteit in de regeltabel, niet in verborgen workflowlogica.
Een andere fout is mensen hard-coderen in plaats van rollen of groepen. Namen veranderen. Teams veranderen. Iemand gaat met verlof of krijgt een andere functie. Als een regel zegt "stuur naar Maria Lopez," moet je die elke keer aanpassen wanneer de bezetting verandert. Het is veiliger om naar een rol zoals Regionaal Finance Manager of Sales Director te routeren en die rol aan de huidige persoon te koppelen.
Het overslaan van een fallback-pad veroorzaakt stille fouten. Vroeg of laat zal een verzoek geen enkele regel matchen omdat het bedrag ongebruikelijk is, de afdeling nieuw is of een veld leeg is. In zo'n geval moet de workflow nog steeds iets veiligs doen, bijvoorbeeld het item naar een standaardwachtrij of admin-team sturen.
Regionale uitzonderingen zijn ook een aandachtspunt. Een beleid dat in één land werkt, werkt mogelijk niet in een ander vanwege lokale bestedingslimieten, belastingregels of rapportagevereisten. Als je slechts één regio test, mis je misschien gevallen waarin EU-, VS- of APAC-verzoeken andere paden moeten volgen.
Tijdgebonden regels worden ook vaak vergeten. Als je een tijdelijke regel maakt voor kwartaal-einde, een budgetbevriezing of een speciaal project, zorg dan dat deze start- en einddatums heeft. Verlopen regels moeten automatisch stoppen met toepassen. Anders blijven oude uitzonderingen actief en sturen verzoeken verkeerd.
Voordat je drempelgebaseerde routering inschakelt, bekijk het vanuit het perspectief van een echte gebruiker. Elk verzoek moet naar de juiste goedkeurder gaan zonder dat iemand moet raden waarom.
Houd de eindcontrole eenvoudig.
Controleer dat elk normaal verzoek één duidelijke match heeft. Als twee regels tegelijkertijd kunnen gelden, krijgen gebruikers inconsistente resultaten.
Zorg voor een fallback-pad. Ontbrekende afdelingen, nieuwe regio's of ongebruikelijke bedragen moeten nog steeds ergens veilig terechtkomen.
Bevestig dat beleidsupdates kunnen plaatsvinden zonder een ontwikkelaar. Als Financiën of Operaties limieten, datums of goedkeurders moet aanpassen, moeten ze records in een tabel kunnen bewerken in plaats van om code-wijzigingen te vragen.
Test datums, niet alleen waarden. Het beleid van gisteren en dat van volgende maand moeten zich beide gedragen zoals verwacht wanneer ingangsdatums meespelen.
Schrijf de routeringslogica op één pagina in duidelijke taal. Als een manager het niet helder kan uitleggen, is het waarschijnlijk te complex.
Een nuttige laatste test is het maken van vijf voorbeeldverzoeken die normale gevallen, randgevallen en verlopen-beleidgevallen dekken. Als je team het resultaat kan voorspellen voordat ze ze uitvoeren, is de opzet waarschijnlijk klaar. Zo niet, vereenvoudig het.
Begin klein. Kies één goedkeuringsflow die vandaag de meeste vertraging of verwarring veroorzaakt, zoals inkoopverzoeken boven een bepaalde drempel of onkostendeclaraties per afdeling. Bouw die eerst, test met echte gevallen en voeg daarna meer regeltypes toe.
Die aanpak maakt het routemodel makkelijker te vertrouwen. Mensen kunnen zien hoe de regels werken, waar uitzonderingen verschijnen en wat er moet veranderen voordat de opzet groeit.
De eerste uitrol moet vier basisvragen beantwoorden:
Dat laatste punt is erg belangrijk. Als niemand duidelijk eigenaar is van beleidsupdates, drijft de workflow langzaam weg van hoe het bedrijf echt werkt. Wijs één persoon of een klein team aan om regelwijzigingen te beoordelen, bewerkingen goed te keuren en kort vast te leggen waarom beleid is veranderd.
Het helpt ook om een beoordelingsschema in te stellen. Als beleid vaak verandert, controleer je de regels maandelijks. Als het proces stabiel is, is een kwartaalcontrole vaak genoeg. Een korte review kan verouderde drempels, ontbrekende afdelingen of regionale uitzonderingen opsporen voordat ze vertragingen veroorzaken.
Houd de review praktisch. Stel simpele vragen: komen goedkeuringen bij de juiste mensen terecht, hebben teams hun structuur veranderd, passen de huidige limieten nog bij het financiële beleid, en zijn er te veel handmatige uitzonderingen?
Als je dit visueel wilt bouwen, kan AppMaster een goede match zijn voor het maken van de regeltabel, het routingsproces en de adminschermen waar niet-technische medewerkers beleid bijwerken. Omdat het is ontworpen voor volledig no-code applicaties, werkt het goed wanneer zakelijke teams goedkeuringswijzigingen rechtstreeks willen beheren in plaats van elke update terug te sturen naar ontwikkelaars.
Zodra één flow goed werkt, hergebruik je hetzelfde patroon in het volgende proces. Kleine, duidelijke stappen werken meestal beter dan een volledige herbouw.
Wat is drempelgebaseerde routering?Het betekent dat de app een goedkeuringspad kiest op basis van regeldetails in plaats van vaste workflow-takken. Bijvoorbeeld: bedrag, afdeling of regio bepalen wie een verzoek goedkeurt, en je kunt die waarden in een tabel wijzigen zonder het hele proces opnieuw te bouwen.
Waarom zijn hard-gecodeerde goedkeuringsregels een probleem?Hard-gecodeerde regels werken in het begin, maar elke beleidswijziging wordt dan ontwikkelwerk, testen en een release. Een regeltabel is sneller omdat de workflow hetzelfde blijft terwijl de beleidswaarden veranderen.
Wat moet ik in een tabel met goedkeuringsregels zetten?Begin met de velden die echt van invloed zijn op routering, zoals minimum- en maximumbedrag, valuta, afdeling, regio, verzoektype, goedkeurdersrol, prioriteit en actieve status. Voor tijdelijke beleidsregels voeg je ook start- en einddatums toe.
Moet ik goedkeurdersnamen of goedkeurdersrollen opslaan?Rollen zijn meestal beter. Als je naar een rol zoals Financieel Directeur of Afdelingsmanager routeert, zijn personeelswisselingen eenvoudiger: je werkt de roltoewijzing één keer bij in plaats van veel regels te veranderen.
Hoe ga ik om met overlappende goedkeuringsregels?Gebruik een duidelijk prioriteitsveld en definieer welke waarde voorrang heeft. Het systeem moet de meest specifieke regel eerst controleren, zodat een nauwe regel zoals EU + Financiën + boven 10.000 wint van een brede regel voor alle afdelingen boven 10.000.
Wat als geen enkele regel bij een verzoek past?Voeg een fallback-regel toe. Als een verzoek ontbrekende gegevens heeft of geen enkele rij matcht, moet het nog steeds naar een veilige wachtrij, admin-team of standaardgoedkeurder gaan in plaats van vast te lopen.
Kunnen niet-technische teams zelf goedkeuringsregels bijwerken?Ja, als het zo is opgebouwd. In AppMaster kun je regels in tabellen houden en het businessproces ze tijdens runtime laten lezen, zodat bevoegde medewerkers beleidsdata via adminschermen kunnen bijwerken zonder code te wijzigen.
Waarom moet ik start- en einddatums aan regels toevoegen?Effectieve datums laten je wijzigingen inplannen en tijdelijke uitzonderingen automatisch laten stoppen. Ze zijn handig voor kwartaal-einde regels, budgetbevriezingen en beleidswijzigingen die volgende maand ingaan maar het huidige verkeer niet mogen beïnvloeden.
Hoe test ik drempelgebaseerde routering vóór lancering?Test echte gevallen vóór livegang, vooral randgevallen. Controleer exacte drempelwaarden, lege velden, nieuwe afdelingen, regionale uitzonderingen en verlopen beleidsregels zodat elk verzoek exact één route heeft.
Wat is de beste manier om met deze aanpak te beginnen?Begin met één goedkeuringsflow die nu de meeste vertraging of verwarring veroorzaakt, zoals inkoopverzoeken boven een bepaald bedrag of onkostendeclaraties per afdeling. Houd de eerste versie klein, bewijs dat de regels werken en pas hetzelfde patroon later toe op andere processen.
10 mrt 2026
7 min
08 mrt 20268 min
07 mrt 20269 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
