Permission models are designed in week three of an implementation, by whoever is available, and then never revisited. Two years later the depot administrator can delete work orders, three people share a login, and nobody can explain who approved a £14,000 repair.
The two dimensions
Every fleet platform's permission model combines two things, and confusing them is the root of most bad designs.
Function — what actions a user can take. View, create, edit, approve, delete, export, configure.
Scope — which records those actions apply to. All vehicles, one depot, one contract, one cost centre, vehicles assigned to me.
A depot manager and a regional manager may have identical function rights and completely different scope. Products that only offer function-based roles force you into duplicated roles per depot, which is where permission sprawl begins.
A reference role set
Start from this and adapt; most fleets need six to eight roles, not twenty.
| Role | Function | Typical scope |
|---|---|---|
| Driver | View assigned vehicle, submit inspections and defects | Own assignments |
| Technician | View and update work orders, record parts and labour | Own workshop |
| Workshop supervisor | Create and close work orders, approve within a limit | Own workshop |
| Depot manager | Full view, approve within a limit, manage assignments | Own depot |
| Fleet administrator | Manage assets, documents, schedules | All, or a region |
| Fleet manager | All operational functions, approve above limit | All |
| Finance | Read-only cost and asset data, export | All |
| System administrator | Configuration, roles, integrations | All |
Two design rules worth holding:
- Approval limits belong to the role, not the person. Otherwise every staffing change becomes a configuration change.
- Read-only roles are underused. Many people who ask for access want to see numbers, not change them. Granting edit rights "to keep it simple" is how audit findings happen.
Data scoping in practice
Scope decisions are harder than they look because organisations are not clean hierarchies.
- A vehicle transfers depot mid-year. Does the old depot manager still see its history? Usually yes for the period it was theirs.
- A shared workshop services three depots. Technicians need cross-depot work order access but not cross-depot cost visibility.
- Contract-based fleets where vehicles belong to customers require scoping by contract as well as by location.
- Regional managers need aggregated visibility across depots without edit rights inside any of them.
Ask vendors to demonstrate these four scenarios with your structure. "We support role-based access control" is a claim about the existence of a feature, not about whether it fits your organisation.
Joiner, mover, leaver
The process discipline matters more than the model design.
Joiner. Access requested by the manager, granted from a defined role template, never by copying an existing user's permissions. Copying is how a warehouse supervisor ends up with system administrator rights inherited from someone in 2021.
Mover. Old permissions removed, not merely supplemented. Accumulated access from three previous roles is the most common finding in any access review.
Leaver. Revoked same day. Integrate with your identity provider so that disabling the corporate account disables platform access automatically — this is one of the strongest arguments for insisting on single sign-on.
Review. Quarterly, by the manager who owns each team, with a signed record. A review nobody signs is not a control.
Shared and generic accounts
"Workshop1", "depotadmin", "driver-tablet". Every fleet has them, and they destroy accountability: no attribution in the audit log, no ability to revoke one person's access, and passwords that circulate indefinitely.
Legitimate alternatives exist for shared devices: a kiosk mode with individual PIN identification, a shared device with individual logins, or per-shift authentication. Insist on one of them rather than accepting a generic account as inevitable.
The audit trail you will eventually need
At some point you will be asked one of these:
- Who changed the PM interval on this vehicle class, and when?
- Who approved this repair above the limit?
- Who closed this defect without a repair?
- Who exported the driver list last March?
- Who deleted these work orders?
Confirm before purchase that the platform logs all five, that logs are immutable, that they are retained long enough to satisfy your policy, and that a fleet manager can query them without raising a vendor support ticket.
Common questions
How many roles should we define?
Six to eight for most fleets. If you find yourself above fifteen, the cause is usually missing scope control — you are creating a role per depot because the product cannot scope a single role by depot. That is a product limitation worth surfacing during evaluation.
Should drivers have accounts in the main system?
They need access to their own app, their assignments and their inspection history — nothing more. Full platform access for drivers is unnecessary and creates both licence cost and risk.
Is single sign-on worth paying extra for?
Yes, in almost every case. SSO makes leaver revocation reliable, removes password reuse, and enables multi-factor authentication centrally. Some vendors gate it behind an enterprise tier, which is a legitimate point of negotiation rather than a reason to skip it.
How do we handle temporary access?
Time-bounded elevation with an automatic expiry, and a record of who approved it. Where the product does not support expiry, use a calendar reminder and a named owner — imperfect but far better than permanent access granted "just for this project".
What should trigger an immediate access review?
A departure, a reorganisation, an acquisition, a security incident, or an audit finding. Beyond those, a quarterly cycle is sufficient for most fleets.
