Guide · Administration
Roles & permissions
Three layers decide what an account can see. Understanding how they combine is the difference between an access model you can reason about and a pile of one-off exceptions.
How access is decided
Role decides which modules exist for you
A role is a named list of visible modules plus a provider flag, defined once in Workspace setup and applied to accounts. Change the role and every account holding it changes with it.
Station scope decides which records you see
Every account carries the stations it can access. Records belonging to other stations are not hidden in the interface — they are not returned at all, so counters, calendars and exports all reflect your scope.
The provider flag narrows it further
An account on a provider role is additionally limited to work rolled out to its own provider company. A contractor sees their jobs at the stations they cover, and nothing belonging to your in-house crews.
Super Admin governs accounts
Creating, editing and deleting user accounts, and resetting passwords, is reserved for Super Admin. That is deliberate: the ability to create an account is the ability to grant access to everything.
Blocked routes fail closed
A module your role does not grant is not reachable by typing its address. The router sends you to an access-denied page rather than rendering a screen the API would refuse to fill.
What typical roles look like
Roles are defined per workspace, so yours will differ. The shapes below are the ones most ground-handling operations converge on, and they are a reasonable place to start.
| Module | Technician | Supervisor | Administrator | Provider crew |
|---|---|---|---|---|
| Dashboard | — | |||
| My day | ||||
| Work orders | ||||
| Refuelling | — | |||
| Daily health checks | ||||
| Asset registry | — | |||
| Inventory | — | — | ||
| Checklist library | — | — | — | |
| Reports & insights | — | — | ||
| Workspace setup | — | — | — | |
| Provider scoped | — | — | — | Yes |
Administering roles
Open Workspace setup → Roles & access
The tab lists every role in the workspace with the modules it grants and whether it is a provider role.
Name the role after the job, not the person
"Line maintenance technician" survives staff turnover; "Dave's access" does not.
Tick the modules the job needs
Start from the smallest set that lets the work happen. Reports and Workspace setup are the two worth withholding by default — one exposes the whole operation, the other changes it.
Set the provider flag for contractor roles
This is what activates provider-company scoping. A contractor role without the flag will see in-house work as well.
Assign stations on the account, not the role
Roles are portable across stations by design. The station list lives on each user account, so the same technician role works at every station you operate.
Re-point accounts before deleting a role
Deleting a role that accounts still reference leaves those accounts without module access. Move them first, then delete.
When someone cannot see something
Work through these in order — the cause is almost always one of the first three.
- Is the module in their role? If the navigation entry is absent entirely, the role does not grant it. Fix it in Workspace setup → Roles & access.
- Is the record's station in their scope? The module is visible but empty, or missing specific records. Add the station to their user account.
- Is the work assigned to them? My day shows only work assigned to the signed-in user. Unassigned station-pool work lives in Work orders until somebody allocates it.
- Is it rolled out to their provider company? For contractor accounts, work rolled out in-house or to a different company is invisible by design.
- Are they on the account they think they are? The account menu in the top bar shows the name, role and station scope currently in effect.
See RampWorks against your own fleet
Tell us how many stations and how much equipment you run, and we will walk the workspace through your operation rather than a demo dataset.