Who Can See What: Role-Based Access Control in Business Systems

Most access problems in business software are not breaches. They are the finance clerk who can quietly amend a posted invoice, the branch manager reading another branch’s margins, and the account of a manager who left in March still working in November. Role-based access control is the discipline that prevents all three, and it fails for a reason that has nothing to do with technology: the roles get drawn from the organisation chart instead of from the work. This guide is about designing them the other way round.

Why the org chart is the wrong blueprint

An organisation chart describes reporting lines and status. Access follows tasks. Those two things diverge from the first day, and every system built on the first ends up with permissions bolted on individually until nobody can say what any role means.

The symptoms are recognisable. Two people share a job title in different branches and need entirely different data. A junior clerk and the manager above her need exactly the same screen, because she prepares what he approves. Someone gets promoted and keeps every permission from the old job plus the new ones, so seniority silently accumulates access rather than changing it. Within two years the answer to “what can a Branch Accountant see?” is “depends which one”.

The alternative is to start from a list of tasks. Who raises a purchase order? Who approves one? Who receives goods against it? Who posts the payment? Who reads the margin? Each of those is a verb with data attached, and roles are groupings of verbs that reliably travel together in your business. When the grouping is right, the role has a name people recognise without being told — and when it is wrong, you will find yourself explaining who the role is for, which is the tell.

Designing role-based access control from the work

A short method that has served us across schools and factories.

List the work, not the people. Walk the process end to end and write down every action that touches the system. This is the part we do on-site, watching the work happen, because the register on the supervisor’s desk and the approval that happens by phone are both part of the process and neither appears in a job description.

Group actions that always travel together. If nobody in the business ever does A without also doing B, they belong in one role. If some people do A without B, that is two roles, whatever the job titles say.

Separate the incompatible ones deliberately. The person who creates a supplier should not be the person who approves payment to it. The person who records goods received should not be the only person who can adjust stock afterwards. These separations are not distrust; they are what makes an honest employee unfalsifiable when a discrepancy appears.

Name each role for the work. “Fee Collection”, “Production Entry”, “Branch Ledger” — names that survive reorganisations, because the work survives reorganisations.

Then attach data scope. A role says which actions; a scope says on whose records — this branch, this unit, this class, this child. That second half only means anything if it is enforced in the database rather than in the screen, which is the distinction we set out in row-level and column-level security.

Least privilege, in plain terms

Least privilege means each role gets what its work needs and nothing beyond it. The practical version is about which direction you move in.

Starting broad and trimming later does not work. Access that has been granted becomes normal, then becomes load-bearing — somebody built a habit on it, somebody’s monthly report depends on it — and removing it feels like an accusation. Starting narrow and widening when a person hits a genuine wall works, because widening is a five-minute conversation with an obvious justification.

Two refinements make it liveable. First, read and write are different privileges: plenty of the people asking for access want to look at something, and giving read access to a report is not the same as giving the ability to change what it reports on. Second, exceptional access should be temporary by design — the cover arrangement while the accountant is on Hajj is a role assigned with an end date, not a permission granted forever because nobody remembered to reverse it.

Worked example: nine roles in a school

Our school management system runs on nine portals, and they are a useful demonstration because the boundaries are so unambiguous.

A parent sees their own child: attendance, results, fee vouchers, notices. Nothing about any other family, and nothing about the school’s finances. A teacher sees their own classes for marks and attendance, plus their own payroll and leave — not the staff payroll, only theirs. Finance sees money across the whole school and nothing academic beyond what billing requires. HR sees staff records including salary; academics sees curriculum, timetable and results without salary. The librarian sees the catalogue, issues and returns — a small, complete world. The student sees their own record. The admin runs the office. Only the super admin sees everything, and there should be very few of those.

Notice how each of these was derived. Nobody asked how senior a librarian is. The question was what a librarian does all day, and the answer produced the portal. Notice also that the roles cut across the hierarchy in both directions: a parent, who is not staff at all, has a portal; a teacher, who is, has a narrower financial view than the accounts clerk.

Worked example: a business with branches

Now a manufacturing group with several units or branches, which is the shape we build most often in ERP development. Here the interesting question is not roles but scope, because the roles repeat at every branch and the data must not.

A branch sales role at Karachi and the identical role at Lahore are the same set of actions on different rows. A branch manager adds approvals and the branch’s own margins. A group finance role reads all branches and posts nothing at branch level. Inventory at each location moves stock in and out of that location only, while a group inventory view exists for the person deciding transfers.

The design test is what happens when you open branch three. If a new branch means creating three new roles and copying permissions by hand, the model was built around locations. If it means creating the location and assigning existing roles with a new scope, the model was built around the work — and that difference compounds every year the business grows.

The audit trail question

Access control decides who may act. It says nothing about who did. For the ordinary disputes of business life — the price that changed between quotation and invoice, the journal entry reversed at month end, the record that is no longer there — you need a log, and the log needs three properties.

It must capture the before value as well as the after: “user X edited invoice 4412” is nearly useless; “user X changed the rate from 480 to 430 at 16:42” settles the argument. It must be immutable to the people it watches — a log that a super admin can quietly amend documents only the honest. And someone must be able to read it without a developer, or it will be consulted approximately never.

Ask any vendor to show you the audit trail for a record you just changed, in the interface, in front of you. It is a fair question and it takes them ninety seconds.

Roles decay unless someone maintains them

The last part is not software. Access lists rot: people join, move between departments and leave, and the leaving is the one that gets forgotten because nobody is inconvenienced by an account that still works. Decide who owns the list, review it on a fixed rhythm — twice a year is enough for most businesses — and make account closure part of the exit routine alongside handing back the keys.

A well-designed role structure makes that maintenance small, which is the whole point: security that requires constant vigilance eventually stops being practised. If you want to see how we translate a walk around your premises into a role map, start with a scoping conversation — it is the same first step as any system we build.