Role-based access control (RBAC) means people in your business software get permissions according to their job, not their name. A "sales rep" role might view and edit its own leads, a "manager" role sees the whole team, and only an "admin" can export data or change settings. You manage a handful of roles instead of hundreds of individual settings, and everyone sees only what their work requires.
Permissions sound like an IT detail until something goes wrong: a departing employee exports the client list, a junior staff member deletes a month of records, or a client logs into a portal and sees someone else's invoice. Each of these is a permissions design failure, and each is preventable.
How do users, roles and permissions fit together?
Permissions are individual actions, roles are bundles of permissions, and users are assigned roles. Change a role once and everyone in it updates.
- Permission: a specific action on a specific kind of data, such as "edit deals" or "export contacts".
- Role: a named set of permissions matching a job, such as "Sales rep" or "Accounts".
- User: a person (or an integration) with one or more roles.
So when a new salesperson joins, you assign the Sales rep role and they're ready. When they move into management, you change their role, and nobody has to remember the forty individual settings involved.
What does a good permission matrix look like?
A simple grid of roles against actions, agreed with the business before anything is built. Here's an example for a service business running CRM, quoting and invoicing in one system.
| Action | Sales rep | Sales manager | Accounts | Operations | Admin | Client (portal) |
|---|---|---|---|---|---|---|
| View leads and deals | Own only | Whole team | No | Won deals only | All | No |
| Edit deals | Own only | Whole team | No | No | All | No |
| Create proposals | Yes | Yes | No | No | Yes | View own only |
| Create and edit invoices | No | No | Yes | No | Yes | View and pay own |
| View deal values and margins | Own deals | Yes | Yes | No | Yes | No |
| Delete records | No | Archive only | No | No | Yes, logged | No |
| Export data | No | Filtered, logged | Financial only, logged | No | Yes, logged | Own documents |
| Manage users and settings | No | No | No | No | Yes | No |
Notice three different levels at work:
- Record level: which records you can see (your own, your team's, everything).
- Field level: which details within a record you can see, such as margins or salary data.
- Action level: what you can do (view, create, edit, delete, export, approve).
Good business software needs all three. A system that only offers "can access the CRM: yes or no" will force you to give people more than they need.
What principles should guide the design?
Start from least privilege: give each role the minimum access to do the job, then add when there's a real need. It's far easier to grant access than to claw it back.
- Least privilege. New roles start with nothing and get specific permissions added.
- Separate duties for money. The person who creates a supplier payment shouldn't be the only one who approves it.
- Archive instead of delete. Most roles should archive records; true deletion is an admin action that gets logged.
- Treat exports as sensitive. Exporting the whole customer list is the action most worth restricting and logging.
- Give integrations their own identities. Your website's form integration should have a narrow key that can create leads and nothing else, not an admin login.
- Keep the number of roles small. If you have more roles than staff, the model has broken down.
Why does logging matter as much as permissions?
Because permissions prevent most problems and logs let you understand the rest. An audit log records who did what, to which record, and when.
Log at least: sign-ins, failed sign-ins, exports, deletions, permission changes and edits to financial records. Make the log readable by the owner, not just by developers, and keep it somewhere ordinary users can't edit.
Security also depends on the doors into the system. On grww.tech we found and fixed a login rate-limit bypass that came from trusting a spoofable IP header, and we removed unsafe-eval from the site's Content Security Policy. Neither is a permissions issue as such, but both show that careful role design is wasted if sign-in protection can be sidestepped.
How should external users like clients be handled?
Clients, contractors and partners need their own roles, scoped strictly to their own records. This is where permission bugs cause the most embarrassment.
GRWW's Ops Console includes a client portal, and the rule that matters most there is simple: a client must only ever see their own proposals, invoices and files. Enforcing that properly means every request for data is checked against the signed-in user's organisation on the server, not just hidden in the interface. Hiding a button doesn't stop someone changing a number in the web address.
Our guide to building a customer portal covers portal design more broadly, and user authentication and roles in web apps goes into sign-in methods from a founder's perspective.
What are the most common permission mistakes?
Shared logins and "everyone is an admin" cause most of the damage we see. Both usually start as shortcuts.
| Mistake | Why it happens | Risk | Fix |
|---|---|---|---|
| Shared logins | Saving on per-seat fees | No accountability; can't remove one person | Individual accounts for everyone |
| Everyone is admin | Quicker than designing roles | Anyone can export, delete or change settings | A permission matrix and least privilege |
| No offboarding process | Nobody owns it | Former staff keep access | A leaver checklist that disables accounts the same day |
| Permissions only in the interface | Rushed development | Data reachable by changing a URL or request | Server-side checks on every request |
| Unlimited exports | Default settings | Whole customer list walks out the door | Restrict, filter and log exports |
| No multi-factor sign-in | Seen as inconvenient | Stolen passwords give full access | Require MFA, at least for admin and finance roles |
Per-seat pricing quietly encourages shared logins. If a vendor charges by user and you're tempted to share accounts to save money, that's worth factoring into a build-or-buy decision. Our comparison of custom CRM vs HubSpot vs Zoho vs Salesforce looks at how seat costs add up.
Does RBAC help with privacy laws?
Yes. Limiting who can see personal data is one of the most practical ways to show you handle it responsibly. The laws differ by country, but the expectation of sensible access control is common.
India's Digital Personal Data Protection Act 2023, Australia's Privacy Act 1988 and Europe's GDPR all expect businesses to protect personal data with reasonable safeguards. Role-based access, audit logs and prompt offboarding are concrete evidence of that. If you're adding AI tools that read customer records, apply the same thinking to them; our checklist of data privacy questions to ask before automating with AI covers what to check.
What does good RBAC cost to build?
In custom software, a solid permission model is part of the core build, not an add-on, and it's much cheaper to design upfront than to retrofit. Retrofitting permissions into a system built without them often touches every screen.
As typical estimates, a custom CRM or ops system with role-based access falls in the US$20k–90k, ₹4–20 lakh or A$30k–150k range depending on scope. Simple role models (three or four roles, record-level rules) add modestly to that; field-level rules, approval workflows and external portals add more. For a view of how permissions fit into reporting, see building a sales pipeline dashboard your team will use, and for the full systems picture, our guide to business systems that scale.
Frequently asked questions
What's the difference between authentication and authorisation?
Authentication confirms who you are, usually with a password, sign-in link or single sign-on. Authorisation decides what you're allowed to do once you're in. RBAC is a way of handling authorisation.
How many roles should a small business have?
Often four to six: something like admin, manager, staff, accounts and an external client or contractor role. Start small and add a role only when a real job can't be served by an existing one.
Can one person have more than one role?
In most well-designed systems, yes. A small-business owner might be both admin and accounts, for example. The permissions combine, so check the result doesn't give anyone more than intended.
What is single sign-on and do we need it?
Single sign-on lets staff use one company account, such as Google Workspace or Microsoft 365, to sign into multiple tools. It makes offboarding much easier because disabling one account removes access everywhere. It's well worth having once you use several business systems.
How often should we review permissions?
Review roles and user assignments at least every six months, and immediately when someone changes job or leaves. A quick review often finds former staff, test accounts or over-powered integrations that should have been removed.
Want permissions designed properly from the start?
We build business systems with role-based access, audit logs and client portals designed in rather than bolted on. See our services or ask for a fixed-price quote.