Rollen en machtigingen uitgelegd met duidelijke voorbeelden, zodat je kunt bepalen wat eigenaren, managers, medewerkers en klanten mogen zien en datalekken kunt voorkomen.
Een “datalek” op het werk ziet er vaak saai uit. Een supportmedewerker opent een klantprofiel en ziet de volledige betaalgeschiedenis. Een klant logt in en ziet interne notities zoals “Bied 20% aan als ze klagen” of de werkelijke kost en marge op een factuur. Niemand heeft een wachtwoord gestolen. De app liet gewoon het verkeerde zien.
De meeste lekken gebeuren per ongeluk. Machtigingen worden laat toegevoegd, een nieuw scherm wordt snel opgeleverd, of iemand kopieert een oude rol die “goed genoeg” was voor testen. Daarna wordt een kleine wijziging, zoals het toevoegen van een nieuw veld, stilletjes zichtbaar voor iedereen.
Daarom moeten rollen en machtigingen eerste klas onderdelen van de app zijn, niet een vinkje last-minute. De meeste kleine bedrijven eindigen met dezelfde vier roltypen: Eigenaar, Manager, Medewerker en Klant.
Het doel is eenvoudig: iedereen ziet alleen wat hij of zij nodig heeft om het werk te doen, en niet meer. Dat geldt voor de data achter de schermen, niet alleen de verwachte schermen.
Als je snel bouwt in een no-code platform zoals AppMaster, wordt dit nog belangrijker. Snelheid is goed, maar het maakt het ook makkelijker om per ongeluk privénotities, prijsregels of andere klantenrecords bloot te geven als toegang niet van tevoren is ontworpen.
Rollen en machtigingen zijn de regels die bepalen wie wat kan doen binnen een app.
Een toegangslevel is het praktische resultaat van die regels. Twee mensen kunnen allebei “Medewerker” zijn, maar de ene heeft een hoger toegangsniveau omdat die restituties kan goedkeuren terwijl de ander dat niet kan.
Een betrouwbare manier om fouten te voorkomen is beginnen met minimale toegang en daarna alleen toe te voegen wat iemand nodig heeft voor het dagelijkse werk. Als iemand nooit facturen bewerkt, geef diegene dan niet “just in case” bewerkrechten. Het is makkelijker om later toegang toe te voegen dan een datalek ongedaan te maken.
De meeste machtigingen komen neer op een kleine set acties: bekijken, aanmaken, bewerken, verwijderen en een paar risicovollere acties zoals exporteren of goedkeuren.
Scope beantwoordt een andere vraag: “Op welke records mogen ze dat doen?” Iemand mag facturen mogen bekijken, maar misschien alleen die van zichzelf, niet van iedereen.
Typische scopemodellen zijn:
Een verkoper kan zijn eigen offertes aanmaken en bekijken, maar niet de volledige klantenlijst exporteren. Een salesmanager kan de offertes van het hele team inzien en kortingen goedkeuren. De eigenaar kan alles zien en rapporten exporteren voor de boekhouding.
De meeste apps hebben uiteindelijk dezelfde vier groepen mensen. De details veranderen, maar het patroon niet. Als je start met duidelijke rollen en machtigingen, voorkom je later veel onhandige “waarom kan die dat zien?”-momenten.
Eigenaren hebben doorgaans volledige zichtbaarheid over het bedrijf nodig. Dat omvat vaak facturatie, beveiligingsinstellingen (zoals wachtwoordregels en MFA) en auditgeschiedenis zodat ze kunnen terugzien wie wat en wanneer heeft veranderd.
Managers moeten een team runnen zonder volledige beheerdersrechten. Zij hebben meestal toezicht nodig (alles in hun afdeling zien), goedkeuringen (kortingen, restituties, verlof, contentwijzigingen) en rapportages. Ze hebben soms beperkte admin-acties nodig, zoals medewerkers uitnodigen of een wachtwoord resetten, maar geen toegang tot facturatie of globale beveiligingsinstellingen.
Medewerkers moeten hun dagelijkse werk snel kunnen doen met minimaal risico. Een veilige standaard is “alleen wat mij is toegewezen.” Een supportagent ziet alleen zijn tickets, een planner ziet alleen de routes van vandaag en een verkoper ziet alleen zijn leads. Exports en bulkdownloads zijn standaard uit en worden pas ingeschakeld bij daadwerkelijke behoefte.
Klanten mogen alleen hun eigen data zien, ook al delen meerdere mensen een account. Laat ze beperkte acties doen (verzoeken aanmaken, facturen betalen, profiel bijwerken), maar verberg interne notities, staff-commentaren en interne statussen.
Een set standaarden die in veel bedrijven werkt:
Veel teams stellen rollen en machtigingen in per scherm: “Medewerkers mogen de Orders-pagina openen, klanten niet.” Dat helpt, maar mist het echte risico. Dezelfde data verschijnt in zoeken, opmerkingen, notificaties, exports en bijlagen.
Begin met het opsommen van je data-gebieden, niet je menu's. Hoog-impact gebieden zijn meestal klantcontacten, orders en leverstatus, facturen en betaalstatus, salarissen en HR-notities, en interne notities of analytics.
Bepaal daarna wat elke rol met elk datatype kan doen: bekijken, aanmaken, bewerken, verwijderen, goedkeuren en delen. Hier doen veldniveau-regels ertoe. Hetzelfde object heeft vaak een publieke en een interne weergave nodig.
Voorbeeld: een Order kan klantnaam, afleveradres, prijs, interne marge en een interne notitie zoals “Klant klaagt vaak, bied korting aan” bevatten. Een klant moet het adres en de status zien, maar nooit de marge of de interne notitie. Een manager ziet alle velden plus de mogelijkheid om kortingen goed te keuren. Medewerkers zien alleen wat nodig is voor levering, maar geen financiële details.
Bestanden en bijlagen verdienen extra voorzichtigheid. Contracten, ID's, bonnen en screenshots bevatten vaak gevoeliger info dan formuliervelden. Behandel ze als een aparte machtiging: wie kan uploaden, wie downloaden en wie kan previews zien. Bepaal ook of bijlagen de toegang van het parent-record erven (zoals een factuur) of eigen regels hebben.
Tenslotte: beschouw exports en bulkacties niet als “inbegrepen” gewoon omdat iemand een lijst kan zien. Maak ze expliciet: export naar CSV/PDF, bulkdownload bijlagen, bulkstatuswijzigingen (goedkeuren, annuleren, restitueren), bulkberichten (email/SMS/Telegram) en admin-acties zoals records her toewijzen.
Stel je een klein dienstbedrijf voor: de eigenaar verkoopt projecten, managers houden toezicht op opdrachten, medewerkers voeren het werk uit en klanten keuren offertes goed en betalen facturen. De snelste manier om ongewenste fouten te vermijden is rollen en machtigingen afspreken voordat iemand inlogt.
Begin met geldzaken. Prijzen kunnen aan meer mensen zichtbaar zijn dan winst. Een veelgebruikte regel: medewerkers mogen zien wat ze moeten rekenen, maar niet waarom die prijs is gekozen. Een technicus heeft misschien regels nodig om een factuur uit te leggen, maar hoeft de interne marge, leverancierskosten of speciale korting die je gaf niet te zien.
Klantgegevens zijn een andere hotspot. Veel teams willen dat meerdere mensen contactgegevens kunnen zien (zodat ze de juiste persoon kunnen bellen), maar slechts enkelen mogen die bewerken. Anders ontstaan per ongeluk overschrijvingen zoals het facturatie-e-mailadres dat vervangen wordt door een privé-email en facturen niet meer bij de boekhouding komen.
Een eenvoudige opzet die voor veel teams werkt:
Beperk risicovolle acties. Een factuur als betaald markeren, een terugbetaling uitvoeren of een betaalmethode wijzigen moet beperkt zijn tot de eigenaar (of een vertrouwde finance-rol).
Een supportdesk lijkt simpel: klanten sturen berichten, je team reageert en tickets worden gesloten. Problemen beginnen als dezelfde ticketweergave voor iedereen wordt hergebruikt. Eén verkeerde instelling en klanten zien interne notities, tags of zelfs staff-performance statistieken.
Stel je een kleine e-commerce met een gedeelde supportinbox voor. Een ticket bevat het klantbericht, ordergegevens, verzendstatus en interne notities zoals “mogelijke fraude, vraag ID” of “VIP, prioritiseer”. Die interne context helpt het team, maar mag nooit zichtbaar zijn voor de klant.
Een duidelijke scheiding die gevoelige data veilig houdt:
Persoonlijke klantgegevens (PII) zijn de volgende valkuil. Support heeft vaak een telefoonnummer of adres nodig, maar niet op elk ticket. Een goede regel: toon gevoelige velden alleen wanneer de workflow ze vereist. Bijvoorbeeld: laat het adres zien zodra de agent “verzendprobleem” kiest, en verberg het weer wanneer het ticket gesloten is.
Houd interne metrics buiten de klantbeleving. Zaken als “tijd tot eerste antwoord”, “agentscore” of “escalatie naar juridisch” horen alleen in staff- en managerweergaven.
Stel je een magazijn en fieldteam voor die de hele dag leveringen uitvoeren. Eén persoon plant routes, een ander verzamelt items en chauffeurs voltooien stops. Als je app de verkeerde details aan de verkeerde mensen toont, is dat niet alleen ongemakkelijk — het kan klantadressen, prijzen of interne notities blootleggen.
Begin met het scheiden van wat elk team dagelijks nodig heeft.
Medewerkers (pickers en chauffeurs) hebben meestal een strakke, taakgerichte weergave nodig. Een chauffeur opent de app en ziet alleen de voor die dag toegewezen taken, met stopvolgorde, contactgegevens voor die stop en bezorginstructies. Ze mogen geen volledige klantenlijst doorbladeren of taken van andere chauffeurs zien. Als iemand een dienst overneemt, kan een manager een taak herverdelen in plaats van brede toegang te geven.
Managers hebben het bredere operationele overzicht nodig. Ze moeten roostergegevens van alle teams zien, voorraadniveaus en wat er nu misgaat (late leveringen, mislukte afleveringen, beschadigde items, ontbrekende handtekeningen). Ze hebben ook tools om uitzonderingen op te lossen: een stop herverdelen, een route splitsen of een voorraadcorrectie goedkeuren.
Klanten hebben de kleinste weergave: alleen hun eigen leveringsstatus. Ze kunnen de ETA volgen, bewijs van levering zien en updates krijgen zoals “uitgeleverd” of “vertraagd”. Ze mogen nooit andere klanten, dagroutes of interne uitzonderingsnotities zien.
Een eenvoudige manier om rollen en machtigingen hier af te dwingen is data te scopen op basis van toewijzing en klantaccount. Bijvoorbeeld: een Delivery Job record is alleen leesbaar voor (1) de toegewezen medewerker, (2) managers, en (3) de klant die aan die order is gekoppeld.
Begin met het benoemen van je gebruikersgroepen in gewone taal. “Eigenaar”, “Manager”, “Medewerker” en “Klant” zijn een goed begin, maar alleen als ze passen bij hoe je bedrijf werkt. Schrijf voor elke groep wat succes eruitziet in één zin, zoals “Managers kunnen werk toewijzen en teamperformance zien zonder payroll te zien.”
Map acties naar data-gebieden. Denk niet eerst in schermen. Denk aan welke data er is en wat mensen ermee moeten kunnen doen. Een simpel schema op papier is genoeg:
Test je concept vervolgens met echte taken, niet met aannames. Loop door veelvoorkomende flows zoals “een order aanmaken”, “een ticket oplossen” en “een rapport downloaden”. Als een taak je dwingt brede toegang te geven, mis je waarschijnlijk een specifieke machtiging (zoals “totaalbedragen bekijken zonder exporteren”).
Voeg goedkeuringen toe waar geld of gevoelige wijzigingen spelen. Medewerkers kunnen een factuur concept maken, maar alleen een manager mag die goedkeuren of verzenden. Medewerkers mogen afleveradressen bewerken, maar bankgegevens wijzigen vereist goedkeuring van de eigenaar.
De meeste datalekken in kleine teams zijn geen hacks. Ze gebeuren wanneer de app iemand stilletjes meer toegang geeft dan nodig is voor het werk. Rollen en machtigingen falen wanneer ze één keer worden ingesteld en nooit meer worden herzien.
Een veelvoorkomend patroon is iemand full admin geven “voor de setup”. De haast is voorbij, maar de toegang blijft. Weken later exporteert die persoon een volledige klantenlijst “om te helpen met een rapport” en gevoelige gegevens liggen in een spreadsheet.
Fouten die steeds terugkomen:
De bijdeuren zijn het sneakyste. Je kunt medewerkers de contractpagina blokkeren, maar ze toch de PDF mailen als bijlage. Of je mobiele layout toont extra velden die op desktop verborgen zijn.
Een praktische fix is exports en downloads als aparte machtigingen te behandelen, niet als een normaal “bekijk”-recht. Als een rol een lijst nodig heeft, geef een gefilterde weergave in plaats van een volledige export.
Voordat je echte gebruikers uitnodigt, ga ervan uit dat iemand op het verkeerde knopje klikt, een scherm deelt of een bestand downloadt dat niet had gemoeten. Een paar checks nu voorkomen later veel gedoe.
Begin met defaults. Als een nieuwe gebruiker wordt aangemaakt, moet die automatisch in de laagste rol terechtkomen, zonder toegang tot geld, exports of admininstellingen. Als iemand meer nodig heeft, maak dat een bewuste wijziging.
Test daarna de klantbeleving alsof je een vreemde bent. Klanten mogen alleen hun eigen records zien, zelfs als ze URL's aanpassen, zoeken of filteren. Een snelle test is inloggen als Klant A en proberen Klant B te vinden op naam, factuurnummer of ticket-ID.
Vijf snelle checks die de meeste lekken vangen:
Doe een “ongeluk-test.” Vraag een collega een echte taak uit te voeren met een medewerkeraccount en probeer daarna dezelfde taak met een klantaccount. Als de klant interne prijzen kan zien, volledige klantenlijsten kan downloaden of een terugbetaling kan activeren, is je permissie te breed.
Een veelvoorkomend verzoek begint zo: een klant wil een portal om “status te controleren”, maar je personeel gebruikt hetzelfde systeem om het werk uit te voeren. Zonder duidelijke rollen en machtigingen kan de portal interne notities, orders van andere klanten of staff-only prijzen blootleggen.
Denk aan een drukkerij op maat. Eén order gaat van offerte naar productie naar levering naar factuur, allemaal in één app.
Dit hoort elke rol te zien in die workflow:
Twee randgevallen breken het model vaak.
Ten eerste: een manager dekt tijdelijk een ander team. Geef die persoon geen Eigenaar. Voeg in plaats daarvan een tijdsgebonden scope toe, bijvoorbeeld toegang tot Team B-orders voor 7 dagen. Als de overdracht stopt, vervalt de toegang.
Ten tweede: een VIP-klant vraagt om “meer zichtbaarheid”. Geef meer context zonder extra data te openbaren. Toon een uitgebreide tijdlijn of een speciale berichtthread, maar behoud interne notities (zoals “klant is laat met betalingen” of “herdruk door onze fout”) als staff-only.
Verantwoordelijkheden veranderen, dus behandel toegang als iets om regelmatig te herzien, niet iets om één keer in te stellen. Als iemand van rol verandert, stapel dan geen permissies op. Verwijder eerst wat ze niet meer nodig hebben en voeg vervolgens het minimale toe voor de nieuwe functie.
Begin klein. Kies één workflow die het meest belangrijk is, zoals “factuur aanmaken en betaling innen” of “supportticket aanmaken en beantwoorden”. Definieer rollen en machtigingen voor die enkele flow eerst en breid daarna uit.
Zet de regels in één eenvoudige tabel en behandel die als een levend document: rol, wat ze kunnen, wat ze niet kunnen en eventuele limieten (zoals “alleen eigen records” of “alleen hun locatie”). Als iemand vraagt: “Mogen medewerkers klanttelefoonnummers zien?”, moet de tabel in seconden antwoord geven.
Een praktische rollout:
Als je op AppMaster (appmaster.io) bouwt, helpt het om rollen naast je datamodel en businesslogica te plannen zodat dezelfde regels consistent gelden voor webapps, mobiele apps en API-endpoints.
Als je wilt, schrijf vandaag je eerste toegangstabel en probeer het op één workflow. Die ene stap voorkomt de meeste onbedoelde datalekken.
Wat is de eenvoudigste manier om rollen en machtigingen te definiëren?Begin met het opsommen van de data die je opslaat (klanten, orders, facturen, interne notities, bestanden), en bepaal vervolgens wie elk item mag bekijken, aanmaken, bewerken, verwijderen, goedkeuren en exporteren. Bouw vanuit minimaal toegangsniveau en voeg alleen toe wat echt nodig is voor het dagelijks werk.
Wat is het verschil tussen machtigingen en scope?Machtigingen bepalen welke acties iemand mag uitvoeren, scope bepaalt op welke records die acties van toepassing zijn. Bijvoorbeeld: een medewerker mag facturen mogen bekijken, maar alleen de facturen die aan hen zijn toegewezen of aan hun locatie horen.
Heb ik echt vier rollen nodig (Eigenaar, Manager, Medewerker, Klant)?“Eigenaar, Manager, Medewerker, Klant” dekt de meeste kleine bedrijven omdat het werk en risico's meestal zo zijn verdeeld. Als je team complexer is, behoud dan dezelfde structuur maar voeg een paar speciale rollen toe (zoals Finance of Aannemer) in plaats van iedereen adminrechten te geven.
Wat mogen klanten zien in een klantportal?Een veilige standaard: klanten kunnen hun eigen records bekijken en acties uitvoeren, maar zien geen interne notities, interne statussen, marges of staff-only tags. Als een klant meer zicht vraagt, geef dan meer context (bijv. een tijdlijn) zonder ruwe velden bloot te geven.
Hoe voorkom ik dat medewerkers marge of gevoelige prijsdetails zien?Scheid ‘wat je in rekening brengt’ van ‘waaróm die prijs bestaat’. Medewerkers hebben vaak de factuurregels en status nodig, maar hoeven meestal geen marge, leverancierskosten, kortinghistorie of betaalknoppen te zien.
Waarom zijn exports en bulkdownloads zo risicovol?Behandel exports als een risicovolle machtiging, niet iets dat automatisch komt met een weergave. Veel datalekken ontstaan doordat iemand zonder na te denken een volledige klantenlijst of factuurhistorie naar een spreadsheet downloadt.
Waarom is het niet genoeg om alleen het scherm te beperken?Schermen zijn slechts één plek waar data verschijnt; dezelfde gegevens kunnen ook in zoekresultaten, notificaties, PDF's, mobiele weergaven, bijlagen en API-antwoorden zichtbaar zijn. Beveilig eerst de datalaag en veldzichtbaarheid, en bouw daar schermen op voort.
Hoe behandel ik machtigingen voor bestanden en bijlagen?Behandel bijlagen met aparte regels; ze bevatten vaak gevoeliger info dan formuliervelden. Bepaal wie kan uploaden, previewen en downloaden, en of bijlagen automatisch de toegang van het parent-record overnemen of een extra toestemming vereisen.
Hoe voorkom ik dat klanten interne notities in een supportdesk zien?Maak twee weergaven van hetzelfde ticket: een klantveilige weergave zonder interne notities, tags of staff-metrics, en een interne weergave met volledige context. Toon gevoelige klantvelden alleen wanneer de workflow ze vereist, zodat agenten niet onnodig adressen of ID's zien.
Welke snelle permissietests moet ik doen voordat ik echte gebruikers uitnodig?Maak demo-accounts voor elke rol en voer echte taken end-to-end uit, inclusief edge-cases zoals zoeken, filteren, bijlagen openen en documenten genereren. Test ook “Klant A probeert Klant B te vinden” met namen, ID's en URL's om te controleren of scope overal gehandhaafd wordt.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
