Role-based access means each person's role, not their individual settings, decides what they can see and do. Employee-built apps need it at two layers: the platform (who can build, who can manage people, who can only use tools) and inside each app (a technician sees their own jobs, a manager sees the whole team, billing details stay with the office). Design roles around real jobs, give each one only the access it needs, and test by signing in as every role before real data goes in.
When a team starts building its own tools, the first version of every app usually has one kind of user: everyone. The builder can see everything, so everyone can see everything. That works for a week. Then a technician scrolls past the owner's margin notes, a part-time worker can delete jobs, or someone who left three months ago still opens the schedule from their phone.
Role-based access is how you prevent all of that without managing permissions person by person. This guide explains it in plain words, shows the two layers every employee-built app needs, walks through designing roles for your company in an afternoon, and gives you a checklist to prove they work.
What role-based access means
Role-based access control, often shortened to RBAC, means you decide permissions for a role once, then give people roles. A role is a job-shaped bundle of permissions: what screens someone sees, which records, and what they can do with them.
Think of it like keys in a building. You do not cut a unique key for every employee. You have a few key types, such as front door, office and supply room, and you hand out the type that matches the job. When someone moves from the warehouse to the office, you swap their key type. When they leave, you take the key back.
The guiding rule is called least privilege: everyone gets exactly the access their job needs and nothing more. Least privilege does not mean distrust. It means a mistake, a lost phone or a misused account can only reach a small part of your business.
Why it matters more for AI-built apps
Access rules are where AI-built apps most often fail. In March 2025, researcher Matt Palmer found 170 of 1,645 scanned Lovable apps exposed because database access rules were missing, recorded as CVE-2025-48757 with a severity of 9.3 out of 10. Lovable disputes the CVE, saying each customer is responsible for protecting their app's data. An August 2026 scan by reeve.page found 57 percent of the 3,553 Lovable app databases it could check had tables readable without logging in. In July 2025, Wiz found a flaw in Base44 that let anyone with a public app ID register on private apps, bypassing single sign-on.
Each of these is an access problem: the rules that decide who can see what were missing, wrong or bypassable. Roles are not just tidiness. They are the main defense.
The two layers of roles
Employee-built apps need roles in two places, and confusing them is a common mistake.
Layer 1: platform roles
These decide who can do what on the building platform itself. A typical set:
| Platform role | Who usually holds it | What they can do | What they cannot do |
|---|---|---|---|
| Owner | Business owner or general manager | Everything, including billing and assigning roles | Nothing is off limits |
| Admin | Office manager or operations lead | Invite and remove people, assign roles, see the activity record | Change billing, unless also owner |
| Builder | People who create and change tools | Build new tools and request changes | Invite people or change roles |
| App user | Everyone else | Use the tools they are given | Change any tool |
The most important line in that table is the last one. Most people in your company need to use tools, not change them. Keeping app users from changing tools prevents a whole class of accidents.
Layer 2: roles inside each app
These decide what each person sees and does inside a specific tool. They are shaped by the work. A few examples:
| Tool | Roles inside the app | Who sees what |
|---|---|---|
| Dispatch board | Dispatcher, technician, manager | Technicians see only their own jobs; dispatchers see all jobs; managers also see performance totals |
| Purchase approvals | Requester, approver, accounting | Requesters see their own requests; approvers see their department; accounting sees everything and marks paid |
| Store audit app | Store manager, district manager, owner | Store managers see their store; district managers see their stores; owner sees all |
| Clinic intake tracker | Front desk, clinician, practice manager | Front desk sees scheduling details; clinicians see their patients; practice manager sees all |
Notice that inside-app roles often limit which records someone sees, not just which screens. "Technicians see only their own jobs" is a record-level rule. These are the rules most often missing in quickly built apps, and the ones that matter most for privacy.
Designing roles in an afternoon
You do not need a consultant. Take one tool and work through these steps with the person who runs that work.
- List every kind of person who touches the work. Not names, jobs. Dispatcher, technician, office manager, owner.
- For each, list what they do. Create a job, update status, approve, see totals, export.
- For each, list what they must see. Their own records, their team's, their location's, or everything.
- List what each must never see. Pay rates, customer payment details, health information, other locations' numbers.
- Group people with the same answers into a role. If two jobs have identical answers, they are one role.
- Write the rules as plain sentences. "Technicians see and update only jobs assigned to them. They cannot see billing notes."
- Pick the smallest set of roles that works. Two to four per app is typical.
- Name an owner for role changes. Usually the admin. Nobody grants themselves access.
A permission grid you can copy
For each role, mark what it can do with each kind of record.
| Action | Technician | Dispatcher | Manager | Owner |
|---|---|---|---|---|
| View own jobs | Yes | Yes | Yes | Yes |
| View all jobs | No | Yes | Yes | Yes |
| Create jobs | No | Yes | Yes | Yes |
| Update job status | Own only | Yes | Yes | Yes |
| Delete jobs | No | No | Yes | Yes |
| See billing notes | No | No | Yes | Yes |
| Export data | No | No | Yes | Yes |
Delete and export deserve extra care. Deleting loses data. Exporting moves data outside the tool, where your access rules no longer apply.
Joiners, movers and leavers
Roles only stay correct if they change with your team.
- Joiners. New people should join only by invite from the admin, with a role assigned before their first sign-in. No public sign-up, no shared logins.
- Movers. When someone changes jobs, change their role the same day. Do not add the new role on top of the old one. Access piles up silently this way.
- Leavers. Remove access on the last day. On a well-built platform this is one step, it ends access immediately, and the tools the person built stay with the company.
Roles for sensitive information
Some records need tighter rules than the rest of a tool. Treat these as their own question every time you design roles:
- Pay and personal details. Employee pay, home addresses and ID numbers belong to the smallest group possible, usually the owner and whoever runs payroll.
- Customer payment details. Most internal tools never need them. If a tool does, limit them to the people who process payments.
- Health information. If your work touches health records, check with your compliance advisor before building, and keep access to the people who need it for care or billing. Our guide to compliance for AI-built apps explains why.
- Margins and pricing. Many owners prefer that field staff see prices but not costs. Decide deliberately rather than by accident.
A useful rule: if you would not print it and pin it to the break room wall, it needs a role rule.
Temporary and seasonal staff
Seasonal workers, temps and short-term contractors are where access most often lingers. Give them the narrowest role that lets them work, note their end date when you invite them, and put the removal on the admin's calendar the day they start. If a person returns next season, invite them again rather than leaving the old access open all year.
Testing that roles work
Roles that look right in settings can still be wrong in practice. Test them.
- Create a test account for every role, at both the platform and app layers.
- Sign in as each role and list what you see. Compare to your permission grid.
- Try a direct link. Copy the link to a record the role should not see, then open it while signed in as that role.
- Change a number in the address bar while signed in as a limited role. You should not reach anyone else's record.
- Try to edit and delete as a view-only role.
- Open the app signed out in a private window. You should see only a sign-in screen.
- Remove a test user and confirm access ends immediately.
- Repeat after every role change, and quarterly.
Our guide to testing an AI-built app before launch puts these checks alongside the rest of a pre-launch test.
Check where roles sit in your plan
On some platforms, role and identity features are only included on top tiers. As listed in October 2026, v0 lists SAML single sign-on and role-based access control as Enterprise only; Lovable lists SCIM (automatic adding and removing of people from a company directory) and audit logs as Enterprise only; and FlutterFlow lists activity logging as Enterprise only. Check which plan includes the controls you need before comparing prices. Our due diligence checklist has a fuller table.
Common mistakes
- One role for everyone. The fastest way to an exposure.
- Giving everyone builder access. Most people need to use tools, not change them.
- Shared logins. You lose the record of who did what, and you cannot remove one person without locking out everyone.
- Screen rules without record rules. Hiding a menu is not the same as limiting which records someone can reach.
- Roles that only grow. People collect access over years unless someone removes it.
- Testing only as the builder. The builder sees everything, so they never see the problem.
How FORGE handles it
FORGE was built with roles at its core, so the right access is the default rather than an upgrade.
- Four platform roles, enforced. Owners, admins, builders and app users each see and do exactly what their role allows. Owners and admins decide who holds a builder seat, and app users use the tools without being able to change them.
- Roles inside every tool, in plain words. When your team describes a tool, they describe who sees what: "technicians see only their own jobs; the office sees billing." Every piece is checked for quality and security before it is saved, and the tool is checked at every step.
- Only the people you invite. Your admin invites each person by email, every invite works once and expires on its own, and there is no public sign-up.
- Every app lives inside your company. Anyone outside gets nothing back, not even a hint the app exists.
- Leavers handled in one step. Removing someone ends their access immediately, and every tool they built stays with the company.
- A complete record. Every step of every build is recorded with who or what did it.
- App users are free. Giving the whole crew the right role never becomes a budget question.
In your workflow workshop, our team helps you map roles for your first tools on your real work. Talk to us.
Questions people ask
What is role-based access control?
Role-based access control, often shortened to RBAC, is a way of managing permissions by role instead of by person. You decide once what a dispatcher, a technician or a manager can see and do, then assign each person a role. When someone changes jobs, you change their role instead of reworking every permission.
What is the principle of least privilege?
It means everyone gets exactly the access their job needs and nothing more. A technician needs their own jobs, not the company's payroll. Least privilege limits the damage from mistakes, misused accounts and departing employees.
How many roles does a small company need?
Usually four at the platform level: owner, admin, builder and app user. Inside each app, two to four roles is typical, such as field worker, office staff and manager. More roles than that usually means the app is trying to do too many jobs.
What is the difference between platform roles and app roles?
Platform roles decide who can build tools, invite people and see the activity record. App roles decide what each person sees and does inside a specific tool. A person can be an app user at the platform level and a manager inside one particular app.
How do I check that roles are working?
Create a test account for every role, sign in as each one, and confirm it sees only what it should. Try opening a link to a record the role should not see, and confirm a view-only role cannot edit or delete. Do this before real data goes in and after every change to roles.
What happens to access when an employee leaves?
On a well-built platform, an admin removes the person in one step, their access ends immediately, and the tools they built stay with the company. Check this before you sign with any platform.
How does FORGE handle roles?
FORGE has four platform roles: owner, admin, builder and app user, each seeing and doing exactly what the role allows. Owners and admins decide who builds, app users use tools without changing them, and inside each tool your team describes in plain words who sees what.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
