Roles & user groups
How the four fixed roles combine with user groups - site-scoped teams that keep work-request notifications and assignee suggestions relevant.
Access in AssetLab is two questions with two separate answers. Roles decide what someone can do - the four-role hierarchy is fixed and applies platform-wide. User groups decide what slice of the organization they work with - which sites, which systems, which kinds of work.
Roles are fixed
There is no per-role capability editor. Administrator, Manager, Staff, and Requester each unlock a defined set of capabilities (the roles capability matrix lists them), enforced at the route, action, and database layers. If you're looking for "Staff, but a bit more" or "Manager, but read-only", the answer is usually the next role up or down - not a customization screen.
That's deliberate: four well-understood roles audit cleanly. The flexibility lives one level down, in groups.
User groups
Settings → Groups (Administrator only). A group bundles members with a scope:
| Scope dimension | Example | What it drives |
|---|---|---|
| Sites | East District facilities | Notification filtering and assignee suggestions |
| System classes | Mechanical, Electrical | Labelling only |
| Work categories | HVAC, Plumbing | Labelling only |
Groups come in two types - operational ("East Crew", "Electrical Shop") and requester ("Arena User Groups", "School A Staff"). The type is an organizing label for the groups list; it doesn't change any behavior.
What groups drive
The behavioral dimension is site. Concretely:
- Work request notification filtering - when a work request arrives for a site, users whose groups don't include that site are excluded from the notification. A user who belongs to no group is unrestricted and receives everything. Small teams often run entirely ungrouped.
- Suggested assignees - the work order form marks group members of the selected site as "suggested" at the top of the assignee list. The full member list stays available - it's a suggestion, not a filter.
- Document folder sharing - document folders can be shared to a group instead of person-by-person.
- Requester organization - requester groups keep a large portal population manageable.
Groups do not auto-assign work requests, and the system-class and work-category scopes are descriptive labels - they don't route anything today. Auto-assignment of work requests is a separate organization setting.
Designing your groups
- Mirror how work is actually dispatched - by district, by trade, or both. If your radio channels are "East", "West", and "Electrical", those are your groups.
- Leave administrators ungrouped. Ungrouped users are unrestricted, which is exactly what oversight roles need.
- Scope narrowly, membership generously. A group scoped to the right sites with a few extra members beats overlapping groups nobody can reason about.
- Revisit at reorganizations. Groups encode your org chart's delivery side; when districts merge, merge the groups the same week.
What groups are not
- Not a fifth role. Group membership never changes what a member is allowed to do - only which notifications and suggestions reach them. Capabilities stay with the role.
- Not the portal boundary. Requester isolation is structural; requester groups organize requesters, they don't expand their access.
- Not cross-organization. Groups, like everything else, live inside one organization.