Roles & Permissions: Deciding Who Can See What
Most access problems are not breaches. They are ordinary people holding permissions nobody meant to give them, in an organization that grew faster than its role model did. How to design roles around the job, why approval must be a separate permission from action, and the review rhythm that keeps the whole thing honest.
Almost every organization starts the same way. Three or four people, all of whom need to do everything, so everybody is an administrator. It works, and it keeps working long after the reason for it has gone — until the day somebody notices that the intern who left in March could still approve purchase orders, or that the whole finance team can delete records nobody can then reconstruct.
That is not a security incident in the dramatic sense. Nobody attacked anything. It is the ordinary result of an access model that was designed for four people and never redesigned for forty, and it is the single most common governance finding in a small growing business.
A role answers two questions, not one
People think of permissions as one question — what can this person see? — when they are really two. What can this person see, and what can this person do? The two come apart constantly, and treating them as one is what produces both of the classic mistakes.
A storekeeper needs to see purchase orders so they know what to expect at the gate; they should not be able to raise one. A branch manager needs to see the payroll cost of their branch; they should not see individual payslips. An auditor needs to see everything and change nothing. None of those are expressible if your model has one dial marked "access".
In AWRA OpsHub the two questions are separated at the level of the individual permission. There are roughly 255 permissions organised into 25 module groups, and within a module they split by action: view, add, edit, delete, and — importantly — approve. A role is a named bundle of those, and you build the bundles that match the jobs you actually have.
Design from the job description, not from the person
The most reliable way to get this wrong is to build roles around individuals. You end up with a role called "Mary" that encodes everything Mary happens to do, and when Mary is promoted the role either follows her — carrying permissions her replacement should not have — or gets cloned into "Mary 2" and the sprawl begins.
-
List the jobs, not the people
Storekeeper, branch supervisor, procurement officer, accounts assistant, finance manager, HR officer, director. Most organizations of under a hundred people have between six and twelve genuine job shapes, and that is roughly how many roles you should end up with.
-
For each job, write the sentence
"A storekeeper receives goods, records issues and counts stock. They do not raise orders, approve anything, or change item costs." One sentence per role, agreed out loud, before anyone opens the permissions screen. This is the part organizations skip and then argue about for a year.
-
Grant the minimum that lets the sentence be true
Start deliberately too tight. A person who cannot do part of their job will tell you within a day, and you grant the missing permission with a reason. A person holding too much will never tell you, because nothing is going wrong from where they sit.
-
Name the role after the job
Storekeeper, not "Warehouse Level 2". The name is read by whoever assigns it to the next hire, and a name that describes a job gets assigned correctly far more often than one that describes a tier.
A person who cannot do part of their job will tell you within a day. A person holding permissions they should not have will never tell you, because from where they sit nothing is going wrong.
Approval is a different permission from action
This is the one design decision that carries most of the control value, and it is worth stating on its own. The permission to raise a purchase order and the permission to approve one are separate permissions, held by different roles, and the whole of segregation of duties rests on keeping them separate.
The same split runs through every module that has a consequence attached — and reading the list is the fastest way to see which parts of your operation are currently uncontrolled.
| Module | The doing permission | The separate approving permission |
|---|---|---|
| Procurement | Raise a request, run an RFQ, create a PO | Approve the request, the quotation, the order |
| Inventory | Record an adjustment, check stock in or out | Approve the adjustment, the check-in, the check-out |
| Assets | Move, assign or transfer an asset | Approve the movement |
| HR | Request leave, log overtime, submit a timesheet | Approve leave, overtime, regularizations, timesheets |
| Payroll | Prepare a payroll run | Approve the payroll run |
| Item master | Propose a change to an item record | Approve the item master change |
| Trash | Send a record to trash | Approve the permanent deletion |
If one role in your organization holds both columns for the same module, you do not have a control there — you have a person you trust, which is a different thing and is not what an auditor is asking about.
The three ways this goes wrong
What organizations actually do
- Everyone who complains gets made an administrator
- Roles are cloned per person, so twenty roles exist for eight jobs
- Permissions are granted in a hurry and never revoked
- Nobody can answer "who can approve a payment?" without checking
- Access is reviewed when an auditor asks, roughly once a year
What holds up under growth
- Administrator is two or three people, and it is a named risk
- Six to twelve roles, each matching a real job description
- Grants carry a reason; leavers are removed the same week
- The approval matrix is a document, not folklore
- Access is reviewed on a rhythm you set, not on an auditor's
Own versus all — the quiet third setting
Between "can see nothing" and "can see everything" there is a third position that most access models forget, and it is the one that fits the majority of staff: a person should see their own records without seeing everybody's.
- An employee views their own payslips, and no one else's.
- A staff member requests their own leave without seeing the leave history of the department.
- A colleague raises a support ticket and follows their own, without reading the whole queue.
- A team member sees the tasks assigned to them without seeing every project in the business.
Where those distinctions exist they are separate permissions, so you grant the narrow one deliberately. Where they do not exist, the honest answer is that the permission is module-wide — and that is worth knowing before you promise a board that "staff only see their own data".
What we do and do not do
What AWRA OpsHub does today
- Custom roles, built by you, from roughly 255 individual permissions across 25 module groups.
- Action-level granularity within each module: view, add, edit, delete and approve are separate grants.
- Separate approval permissions for procurement, adjustments, asset movements, leave, overtime, timesheets, payroll runs, item-master changes and permanent deletions.
- Own-record permissions where they exist — own payslips, own leave requests, own tickets, own tasks.
- Sensitive-data permissions held apart from ordinary access: viewing sensitive custom fields and exporting sensitive reports are their own grants.
- An audit log that records administrative actions with the actor, the route, the IP address and the time, so a permission change is a recorded event.
More we can add to your workspace
- Row-level sharing rules — a "this salesperson sees only their own customers" rule you define. Outside the specific own-record permissions listed above, a permission is module-wide today.
- Field-level security across the board. Sensitive custom fields and sensitive report exports are gated; ordinary fields on ordinary records are not individually restrictable.
- A time-boxed or temporary access. A grant does not expire on a date you set; removing it is a deliberate act by an administrator.
- An approval chains built out of roles alone. Multi-step and conditional approvals live in the automation layer, not in the permission model.
Read the right-hand column before designing a control around something you assumed was there. Two of those four are the assumptions organizations most often make out loud in a board paper.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe review rhythm
A role model is not a project you finish. It decays every time someone joins, leaves, is promoted or covers for a colleague "just for this month", and the decay is invisible because it never breaks anything. What keeps it true is a short, boring, scheduled review.
- Quarterly: list every user and their role, and have each department head confirm their own people. Fifteen minutes each, and it catches leavers, movers and holiday cover that became permanent.
- Quarterly: list everyone holding an administrator role and justify each one by name. If the list has grown, that is the finding.
- On every exit: remove access the day employment ends, not the day the laptop is returned. These are two different dates and only one of them is under your control.
- On every promotion: replace the role, do not add to it. The old permissions are the ones that accumulate.
- Annually: re-read each role's one-sentence description against what the job has actually become.
Our take
Write one sentence per job before you touch a permissions screen, keep approve separate from do in every module that has consequences, and review the whole list quarterly in fifteen-minute conversations with department heads. That costs an hour a quarter and removes most of what an auditor would otherwise find.
See governance and roles in AWRA OpsHub
Custom roles built from action-level permissions across every module, separate approval grants, and an audit log that records who changed what.
Explore governance & rolesFrequently asked questions
How many roles should a growing business actually have?
Between six and twelve for most organizations under a hundred people, because that is roughly how many genuinely distinct job shapes exist. If you have more roles than jobs, you have almost certainly built roles around individuals rather than around work, and the sprawl will keep growing. If you have fewer — one "staff" role and one "admin" role — the admin role is doing far too much and is where every access finding will come from.
Is it safe to make someone an administrator temporarily?
It is safe if the removal is scheduled at the moment of the grant, and unsafe otherwise, because there is no expiry on a permission — it stays until an administrator deliberately removes it. In practice "temporarily" is how most over-privileged accounts are created. If you must do it, write the removal date in the same message where you approve the grant, and treat the quarterly administrator review as the backstop.
Can we stop a salesperson from seeing other salespeople's customers?
Not with a general rule. Permissions are module-wide except where a specific own-record permission exists — own payslips, own leave, own tickets, own tasks. Customer records are not among them, so anyone with customer access sees the customer list. If that separation is a hard requirement for you, say so early rather than assuming it is a setting; it is a data-visibility model change, not a checkbox.
What is the difference between the permission model and an approval workflow?
The permission model decides who is allowed to approve at all. The automation layer decides the sequence — who first, what threshold escalates to whom, and what happens if nobody acts. You need both: a workflow that routes an approval to someone who lacks the approval permission cannot complete, and an approval permission with no workflow around it means whoever happens to open the record approves it.
Are permission changes themselves recorded?
Yes. Administrative actions are written to the audit log with the actor, the action, the module, the route, the IP address, the user agent and the time. That matters more than it sounds: the question an auditor asks is rarely "who approved this payment" — it is "who gave that person the ability to approve payments, and when". Without a record of the grant, the approval trail has an unexplained beginning.
