Roles & access
The four AssetLab roles, what each one can do, and how to choose the right one when inviting your team.
AssetLab uses four hierarchical roles. Each role includes everything the roles below it can do - a Manager can do anything Staff can, plus more.
The four roles
| Role | Typical person | Summary |
|---|---|---|
| Administrator | System owner, IT lead | Full control - users, settings, billing, API keys, all data |
| Manager | Supervisor, department head | All operational data plus projects, reporting, and approvals |
| Staff | Technician, operator | Day-to-day work - assets, work orders, PMs, work requests |
| Requester | Occupant, tenant, resident | Self-service portal only - submit and track their own requests |
What each role unlocks
Requester
Requesters never see the main application. They land in the requester portal, where they can submit a work request with photos and track the status of their own submissions. Use this role freely - building occupants, school staff, arena user groups - it cannot see your asset data.
Staff
Staff work the queue: view and update assets, create and complete work orders (including the work orders PM schedules generate), consume parts, and manage vendors, contracts, compliance, and expenses. They see organization members (for assignments) but cannot invite users, change settings, or access projects and reporting.
What Staff cannot open: the PM schedule pages, Forms, Documents, Classifications, and Categories are all Manager+ surfaces. Staff execute the work orders a PM schedule produces without seeing the schedule itself.
Manager
Managers add the planning layer: projects, budgets, reporting, dashboard exports, approvals of work requests, PM schedule and forms management, and document, classification, and category administration. Choose Manager for anyone who owns a budget or signs off on work.
Administrator
Administrators additionally control the organization itself: inviting and removing users, role assignment, organization settings, custom fields, API keys, webhooks, and data import/export. Keep this group small - two or three people in most organizations.
How access is enforced
Role checks apply at three layers, and all three run on every request:
- Routes - pages a role cannot use are unreachable, even by direct link.
- Actions - buttons and forms above your role don't render.
- Database - every query is checked server-side against your organization and role. UI tricks can't bypass it.
The same model applies to API keys, except keys use explicit scopes instead of roles.
User groups
Roles set what someone can do; user groups (Settings → Groups) set which slice of the organization they work with. A group bundles members with a site scope, and AssetLab uses it two ways: incoming work request notifications skip members whose groups don't include the request's site, and the work order form marks group members of the selected site as suggested assignees. Document folders can also be shared to a group at once. Users in no group are unrestricted - the right default for small teams and administrators.
The full capability-by-role breakdown lives in the roles capability matrix; group setup is covered in Roles & user groups.
Related
- Users & invitations - inviting, removing, and auditing users.
- Roles & user groups - group setup and routing in depth.