User roles and permissions: deciding who should see what
Set access too open and the data degrades. Set it too tight and people work around the system. The workable line sits in a fairly specific place.
Permissions are usually configured once, during implementation, by whoever is available — and then never revisited until something goes wrong. Two failure modes result, and they look nothing alike.
Too open, and cost fields get edited by people guessing, asset records get renamed to suit one team, and the history stops being trustworthy. Too tight, and technicians cannot close their own work, approvals bottleneck on one account, and the workaround becomes a WhatsApp group that no auditor will ever see.
Five roles cover most operations
- Requester — raises faults, sees the status of their own requests, edits nothing else. Usually operators.
- Technician — sees assigned work, records findings, logs time and parts, closes work. Cannot alter cost or approvals.
- Planner — creates and schedules work, manages PM tasks and the asset register. Cannot approve spend.
- Approver — approves within a stated threshold, sees cost across their scope. Often does not need to edit work at all.
- Administrator — configures the system, manages users. A small number of named people, ideally two.
Resist inventing a sixth role for one person’s convenience. Role sprawl is how permission systems become unauditable.
Cost is the field to protect
Technicians should record what was used — hours, parts, contractor attendance — and should not be able to set what it cost. This is not about trust; it is about a single source for pricing. When cost can be typed anywhere, cost reporting quietly becomes fiction, and nobody notices for a year.
Give contractors scoped access, not email
A contractor working outside the system is a contractor whose quotes, diagnoses and completion notes live in someone’s inbox. Scoped access — their jobs, the relevant asset history, the agreed rate card, and nothing else — puts their contribution into the record without exposing your estate.
It also removes the forwarding step, which is where information most often stops.
Approval authority is a permission, not a convention
If your threshold rule exists in a policy document rather than in the system, it is advisory. Encoded as a permission, it applies at two in the morning to whoever is on shift, which is the entire point of having a rule.
Every approver needs a named alternate with equal authority. Most approval delays are absences, not disagreements.
Review access when roles change
The step everyone skips. A technician promoted to planner usually keeps both sets of rights, and after three years the permission map bears no relation to the organisation chart. A twenty-minute review each quarter, comparing the user list against current roles, prevents a problem that is very tedious to unwind later.
Related reading
Run this workflow on a system built for it
Every step in this guide maps to something SaharaDesk does out of the box. Book a demo and walk it against your own assets.