Designing User Roles Before Go-Live
Two hours before go-live, permission design is free — nobody has a habit to defend. Six months later the same conversation costs a week and makes enemies. How to design roles from the segregation you actually need, against 255 permissions in 25 groups, and where the model stops.
The default at go-live is to give everyone everything, because the priority is that nothing blocks the rollout and the plan is to tighten it later. Later is not a date. What actually happens is that by month six the audit trail records that seventeen people could have made the entry, approval has quietly stopped meaning anything because approvers can approve their own requests, and whoever proposes tightening it becomes the person breaking someone's workflow.
Designing roles before anyone gets a login takes about two hours and costs nothing politically, because there is no incumbent expectation to disappoint. It is the cheapest control in the whole implementation and the one most reliably skipped.
Start from the separations, not from the job titles
The instinct is to list the staff and give each of them what they need. That produces one role per person, which is not a design — it is a spreadsheet. Start instead from the four separations that matter in a small business, and build roles that enforce them.
The four separations, in order of what they protect
Whoever asks may not approve
Requesting and approving are separate grants throughout — approving purchase orders, expenses and high-value stock adjustments each have their own permission rather than riding on the edit right. On expenses and high-value adjustments the self-approval block is absolute and not overridable by any grant.
Whoever receives may not adjust
Receiving stock and writing stock off are different rights. This is the separation that catches the oldest trick in warehousing: receive short, adjust the difference away, keep the goods.
Whoever holds the stock may not count it alone
Blind counting is enforced and disclosure sits behind its own permission, so the system supports this. Whether the storekeeper is one of the counters is a policy you set — there is no rule preventing it.
Whoever pays may not create the payee
Creating a vendor and paying a vendor are separate permissions, so the design is available. Nothing stops you granting both to one person, and in a five-person business you may have to — in which case compensate with a monthly review of new vendors rather than pretending it is covered.
The first two are enforced by the system; the second two are available and depend on you. Knowing which is which is the difference between a control and a belief.
The permission model, precisely
There are 255 permissions organised into 25 groups. Beyond the obvious per-module view and edit rights, three patterns are worth designing around because they let you be more precise than "yes" or "no".
- Separate
approve_*grants. Approval is never implied by the ability to edit. This is what makes the requester-approver split real rather than procedural. view_own_*variants on payslips, tasks, tickets and leave. Staff see their own records without seeing everyone's — which is what you want for payslips in particular, and what most SMEs get wrong by giving HR-wide visibility to a supervisor who needed one person's leave balance.- Specific high-consequence grants carved out on their own: overriding a payment match, approving a high-value adjustment. These exist so you can withhold one dangerous capability without withholding the whole module.
And the boundary, stated clearly: there is no row-level security. Permissions are per module and per action, not per record, branch or department. Someone who can view customers can view all of them. If you need a Mombasa manager who sees only Mombasa customers, that shape does not exist here — the nearest workable approximation is separate warehouses and locations for stock, which does scope stock views, and accepting that master data is visible organisation-wide.
A five-role design for a 40-staff distributor
| Capability | Store | Buyer | Finance | Manager | Admin |
|---|---|---|---|---|---|
| Raise a purchase requisition | Yes | Yes | Yes | Yes | Yes |
| Approve a purchase order | No | No | Yes | Yes | Yes |
| Receive stock against an order | Yes | No | No | Yes | Yes |
| Adjust or write off stock | Partly — configurable by you | No | No | Yes | Yes |
| Approve a high-value adjustment | No | No | Yes | Yes | Yes |
| Create a vendor | No | Yes | No | Yes | Yes |
| Pay a vendor | No | No | Yes | No | Yes |
| See all payslips | No | No | Yes | No | Yes |
| Change roles and permissions | No | No | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The half marks are deliberate: the store can raise an adjustment but not approve one above the threshold, which is the whole point of having a threshold. Note also that the manager cannot pay and finance cannot approve their own — cross the two and you have removed both controls at once, which is the most common quiet failure in a design that looks sensible on paper.
How many administrators is the right number
Two. Three at a stretch, in a business of a hundred people. The number matters because an administrator can change permissions, which means every other control in your design is conditional on that person choosing not to change it.
The reason organisations end up with nine is not carelessness — it is that the administrator right is the fastest way to unblock somebody at 4pm on a Friday. Which is why the useful counter-measure is not a policy about administrators but a named person whose job includes granting things quickly, so that nobody needs to be made an administrator to get on with their afternoon.
The two-hour session, in order
- List the four separations above and decide, for each, whether you can genuinely enforce it at your headcount. Write down the compensating check where you cannot.
- Define no more than six roles. More than six in an SME means you are describing people, not functions.
- For each role, decide what it may approve — separately from what it may edit. This is the step that gets merged, and merging it is what makes approval decorative.
- Set the thresholds while you are here: the value above which a stock adjustment needs a second person, and the value above which an expense needs approval at all.
- Count the administrators. If more than three, name the person who will grant things quickly instead.
- Decide the MFA policy — required or recommended, organisation-wide. There is no per-role setting, so this is one decision for everyone.
- Write the whole thing on one page and keep it. In eight months somebody will ask why the storekeeper cannot write off damage, and the page is the answer.
What the model does not give you
What AWRA OpsHub does today
- 255 permissions across 25 groups, with approval as its own grant everywhere it matters.
- `view_own_*` variants on payslips, tasks, tickets and leave.
- Absolute self-approval blocks on expenses and high-value stock adjustments — not overridable by any permission.
- An audit trail recording actor, action, module, route, IP, session and subject on every change, plus selected read routes such as exports and report views.
- MFA by TOTP with recovery codes, set organisation-wide as required or recommended.
- A leaver reconciliation screen that revokes a linked login and clears sessions on termination, and separately lists active accounts with no employee record behind them.
What it does not do
- No row-level security. Permissions are per module and action, never per record, branch or department.
- No time-bound permission grants and no account expiry date, so a contractor login cannot lapse on its own.
- No access review campaign — nothing prompts a periodic re-approval of who has what.
- No conflict detection on dangerous permission combinations. Granting one person both "create vendor" and "pay vendor" produces no warning.
- No per-organisation password policy and no configurable lockout threshold.
- MFA is TOTP and recovery codes only. There is a WebAuthn implementation, but it is for attendance verification, not sign-in — do not conflate them.
The absence of access review campaigns is the one that compounds: permissions only ever accumulate, because granting solves a problem today and revoking solves one nobody has noticed yet. The manual substitute is a diary entry every quarter and twenty minutes with the role list.
For the wider picture, roles, permissions and access control covers the model in depth and the audit trail covers what gets recorded once your design is in place.
Our take
Do the two hours before anybody gets a login. Design from the four separations rather than from job titles, keep it to six roles and two administrators, set your thresholds in the same session, and write it on one page. Then put a quarterly diary entry in to re-read it, because nothing in the system will ever ask you to.
Design the roles before the logins go out
Approval as its own grant, own-record visibility where it belongs, absolute self-approval blocks on spend, and an audit trail behind all of it — with the row-level boundary stated up front rather than discovered in month six.
See plans & pricingFrequently asked questions
How many roles should an SME define?
Six at most. More than six usually means you have described people rather than functions, which produces a design that has to be re-cut every time someone is promoted or leaves. Start from the separations you need to enforce — requester versus approver, receiver versus adjuster, holder versus counter, payer versus payee-creator — and build roles that carry them.
Can we restrict a user to one branch or one location?
Not for master data. There is no row-level security: permissions are per module and per action, so someone who can view customers sees all customers. Stock views do scope by warehouse and location, which gives you a workable approximation for physical operations, but a "Mombasa manager who sees only Mombasa customers" is not a shape this model supports.
How many administrators should we have?
Two, three at a stretch in a business of a hundred. An administrator can change permissions, so every other control in your design is conditional on that person not changing it. Organisations drift to nine because admin rights are the fastest way to unblock someone on a Friday afternoon — the fix is naming somebody whose job includes granting things quickly.
Does the system stop someone approving their own request?
On expenses and high-value stock adjustments, yes, absolutely, and the block cannot be overridden by any grant. Elsewhere, approval is a separate permission from editing, so the separation is available to you by design but is not universally enforced by the system. Grant approval rights to people who did not raise the work.
Are permissions reviewed automatically?
No. There is no access review campaign, no time-bound grant and no account expiry, so permissions only ever accumulate — granting solves a problem today, revoking solves one nobody has noticed. The substitute is a quarterly diary entry and twenty minutes with the role list. There is a leaver screen that revokes a linked login on termination and separately lists active accounts with no employee behind them, which catches the worst case.
Is multi-factor authentication available?
Yes — TOTP with recovery codes, set organisation-wide as either required or recommended. There is no per-role MFA setting, so it is one decision for everyone. There is also a WebAuthn implementation in the product, but it is used for attendance verification rather than as a sign-in method, and the two should not be confused when comparing vendors.
