Deciding who may see the purchase price takes longer than building the screen that hides it.
Every business system reaches this requirement, and on most projects it is the one that slips. Not because it is difficult to build. Because it asks the business a question it has been avoiding: does the branch manager see the other branch, and does the salesman see what the item cost you.
We would rather have that argument in week one, with the owner in the room, than discover it during training when a supervisor sees a salary.
Role-based access control means permission belongs to a role rather than to a person. You define a branch manager, an accountant and a field executive once, say what each may do, and then give people roles. When somebody is promoted or leaves, you change their role instead of hunting through a list of individual ticks.
Where it earns its place.
Roles are the easy half
Naming the roles takes an hour. Deciding scope takes a week, and scope is what people actually mean when they say permissions.
- Which records: this branch, my own customers, my own team, everything
- Which fields: the margin, the purchase price, the salary, the phone number
- Which actions: raise it, edit it, approve it, cancel it after approval
- Up to what value: a discount or a credit note above a limit goes upward
What we are asked for most
These come up so often that we now raise them before you do.
- A branch manager who sees only their own branch, with the owner seeing all of them
- Purchase price and margin hidden from the sales team on the same screen
- Maker and checker, where the person who raises a credit note cannot approve it
- A dealer or customer portal on the same system, seeing only their own account
- A receptionist who can book but not open a case sheet
Where it is enforced
A hidden menu item is not access control. If the address is typed by hand or the API is called directly, the record still comes back.
- Every query filtered on the server by who is asking
- The interface hiding what the server would refuse anyway
- Fields removed from the response, not merely blanked on the screen
- Reports and exports covered by the same rules as the screens
Exports are where this is most often missed. A report screen that respects the branch rule, next to a download that quietly contains everything.
How we work it out
- List the jobs
- List the records
- Agree scope
- Write the matrix
- Build
- Review
- Starting from the jobs that exist in your organisation, not from software roles
- A grid on one page: roles down the side, records across the top
- The owner signing off the awkward squares before anything is built
- An admin screen where you can change it later without calling us
The day somebody leaves
Permissions are not a build task. They are a thing that rots, quietly, in the direction of everybody having more access than they need.
- One named person who approves who gets which role
- Access removed the day a person leaves, not at the next audit
- Temporary cover that expires by itself
- A list, twice a year, of who can see the most sensitive records
When this is the right choice.
- Several branches, departments or franchises on one system
- Outsiders on the same software: dealers, customers, doctors, parents, vendors
- Money, margin, salary or patient records that not everybody should see
- Approvals that must sit with somebody other than the person raising them
- A system your team will run themselves, where roles change without a developer
When it is not.
- A handful of people who genuinely all do everything, where roles add friction and no safety
- Rules that differ for every single person, where you end up with one role each and attribute rules would fit better
- A business that will not name one person to own who gets which role, because the model decays within months
- Hiding a menu while the API still answers, which looks like access control and is not
Questions we are asked about it.
How many roles should we have?
Fewer than you expect. Start from the jobs that already exist in the business, which is usually five or six. Add a role only when two people in the same job genuinely need different access. A system with twenty roles is normally a system where nobody agreed the scope.
Can one person hold two roles?
Yes, and in a small business it is common: the branch manager who also does accounts. We build so that permissions add up rather than clash. What we do not allow is a combination that defeats an approval rule, such as raising and approving the same credit note.
Can we change permissions ourselves later?
That is how we build it wherever we can, with an admin screen where a named person edits roles. Some rules are structural and do live in the code. We tell you which is which before go-live so nobody is surprised by a change request.
Should the owner be able to see everything?
Usually yes, and it should still be logged. The account worth thinking twice about is the emergency administrator that every system has. Keep it, restrict who holds it, and record every time it is used.
Does this make us compliant with the data protection rules?
It is one part of it and not the whole. Access control limits who can see personal data, which is a real requirement. Consent, retention, deletion and what your vendors do with the data are separate questions that need separate answers.
Can this be added to software we already run?
Often, though the cost depends on how the original was written. If permissions were checked on the screens rather than in the queries, the work is in the queries and it is real work. We audit first and tell you the size of it before starting.
Services that use it.
Not sure Role-based access control is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private