Who may do what: roles and permissions a business system needs

A permission is a sentence with four parts, and most business systems write only two of them. That is why the model fails in one of two directions: one shared administrator account that can do everything, or forty roles that nobody can explain and everyone works around. Both end in the same place — nobody can say, for a named person and a named record, what that person may do.

What four questions does every permission answer?

Who — an identity, not a department, a job title or a shared account. "The sales team" is not a who; it is a group of people who will each need different access within six months.

On which record — the scope, which is usually harder than the verb. "Edit orders" is not a permission until it says whose orders: the ones they created, the ones of their branch, or all of them. Most arguments about permissions are about a scope nobody wrote down.

Which action — read, create, edit, delete, approve, export. A permission called "manage" hides six decisions in one word, and the two that matter are usually approve and delete.

Under what condition — the part almost everyone omits. An order may be edited until it is invoiced, and not after. A discount may be given below a limit and needs approval above it. A price may change during the month and not once the month is closed. Conditions are where the business rule actually lives; a system that ignores them pushes the rule back into a WhatsApp message.

Why is a role not the same as seniority?

Because a role is the bundle of permissions a job needs, and seniority is a claim about rank. They overlap often enough that people stop distinguishing them, and then the bundle is built from the org chart.

Two things follow. The person with the most authority often needs the fewest permissions: an owner who reads a monthly summary does not need to edit a purchase order, while the accountant closing the month may need to correct almost everything. And two people with the same title can need different rights — the warehouse supervisor and the purchasing manager may require identical access while sitting in different departments.

Name the role after the work, not the person holding it: counter sales, stock receiving, month close. A title outlives the work it described, and nobody revisits a role called "Manager".

What about a field one person may see and another may not?

The cashier needs the customer's phone number to call about a delivery, and must not see the credit limit. The usual answer — the whole customer record is one permission — forces a choice between blocking the phone call and publishing a number that belongs to a commercial decision.

Field-level rules earn their complexity for a short list: cost and margin, credit limit, salary, supplier price, identity numbers. Keep the list short and write it down. Everything else should be a screen decision: the counter screen shows what the counter task needs, the accounts screen shows the rest, and opening the second one is its own permission.

There is a second reason to hide it, and it is not security: a number on a screen in front of a queue gets read aloud and argued over in front of other customers.

What changes when there is more than one branch?

Location is a dimension of the permission, not a second role. "Store manager" is one role; the person holding it has a scope of one branch or four.

Three failures repeat. The scope is taken from the account's default branch, so it is silently wrong the day someone covers a shift at another shop. The head-office user has to pick a branch on every screen because the system has no "all branches" scope. A transfer between branches needs someone who can see both ends, and that is usually nobody.

Question	A weak answer	An answer that works
Who	One shared admin login	A named person with their own credentials
Which records	"Everything in the module"	This branch, or the records they created
Which action	"Manage"	Read, create, edit, approve, export, separately
Revoking it	Change the password	Disable one account, effective today

How do you get to a short list of roles?

1. List the five or six jobs people actually do in a week, as verbs: take an order, price it, confirm stock, prepare the delivery, post the invoice, close the month.
2. Sit with one person doing each job for an hour and note every screen and button they touch.
3. Merge any two roles that differ by one permission. Two roles that differ by one field are one role plus a field rule, or a modelling mistake.
4. Give each person the smallest set that lets them finish the day without asking a colleague. If they must ask daily, the set is wrong and they will be handed a shared password within a month.
5. Write the four answers for each role on one page and ask a non-technical manager to restate it. If they cannot, the role is not finished.
6. Test revocation the same week: disable a test account and confirm the very next request is refused, not the next login.

Where this goes wrong

• The check runs in the interface. Hidden buttons are not a permission; the request is still accepted by a server that trusts it. Broken access control stays at the top of the OWASP Top Ten for exactly this reason.
• The permission is read once, at login. Change a role in the admin screen and the person keeps the old set until their session ends, sometimes for weeks. A permission you cannot revoke tomorrow is not a permission; it is a fact.
• Forty roles because each person got one. That is a personal account with extra steps, and nobody can explain any of them.
• Permissions modelled on the menu. A screen is not a permission. Two screens that edit the same record are one permission, whatever the navigation says.
• The permanent administrator account, kept "just in case". It is a bypass in every conversation about access. If it has to exist, give it its own name, its own trail and a rotation date.
• Temporary access with no end date. It outlives the project because nobody owns the date.

What this does not cover

Nothing here tells you which roles your business needs — that comes from watching the work, and it changes when the work does. This is not about authentication mechanics: password storage, sessions and reset flows are a separate subject with a good reference of their own. And it assumes the system is yours to change: in a packaged product, part of this is configuration you can ask for and part is not for sale.

We build systems where every permission answers who, on which record, which action and under what condition — and where removing one is a single action, today.