Roles & user groups

The three layers of access - role, workspace and user group - and how user groups limit which sites and networks each member sees.

Access in AssetLab has three layers. Each answers a different question, and together they decide what a member can do and see.

• Role is the four-role hierarchy: fixed capabilities, from full control for Administrators down to the request portal for Requesters.
• Workspace splits the app in two. Facilities is organized by site, building and location - the assets inside your buildings. Infrastructure is spatial - networks of features on a map, such as roads, pipes and street lights. A Manager or Staff member can be given facilities only, infrastructure only, or both. It trims the menus and lists to one side; it is not a security boundary, and Administrators always see both.
• User group decides which records a member sees, and it is enforced by the database on every screen, the map, dashboards and exports. A site-based group limits a member to its sites. A network-based group limits them to its networks: put a member in a group that lists only Street Lighting, and they see only street light features and the work orders, PMs, projects, routes and corridors on them. A member in no group sees everything, and Administrators always do.

The sections below cover roles and groups in detail; workspaces are covered under Users & invitations.

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:

Groups come in two types - operational ("East Crew", "Water Crew") and requester ("Arena User Groups", "School A Staff"). Only operational groups take auto-assigned work; requester groups never do.

Infrastructure groups

Organizations with the Infrastructure module choose a workspace when they create an operational group:

• Facilities teams cover sites, exactly as before.
• Infrastructure teams cover networks instead of sites, and their category list shows only infrastructure and shared work categories. An infrastructure team never narrows what its members see in Facilities.

A group's workspace is set when it is created. Requester groups are shared by both workspaces: one group can list sites and networks, and a requester whose groups list networks picks only features in those networks on the requester portal. A group that lists networks and no sites doesn't narrow what its members see in Facilities.

What groups drive

• Visibility - members of a Facilities or requester group see only the sites their groups list, and the records on them. Members of a group that lists networks see only those networks: their features, routes, corridors, zones, infrastructure work orders, PMs and requests, and the projects and vendors tied to them, on every screen, the map and the dashboards. A user who belongs to no group is unrestricted, and Administrators always see everything. Small teams often run entirely ungrouped.
• Auto-assignment - when auto-assignment is on, a new work order is assigned to the groups covering its site, or, for infrastructure work with no site, its networks: a specialist group for the matching work category first, falling back to a group with no category restriction. See work requests for how the same match gates auto-approval.
• 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. For a request about an infrastructure feature, users whose groups list networks but not that feature's network are excluded too.
• 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.

Designing your groups

1. 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.
2. Leave administrators ungrouped. Ungrouped users are unrestricted, which is exactly what oversight roles need.
3. Scope narrowly, membership generously. A group scoped to the right sites with a few extra members beats overlapping groups nobody can reason about.
4. 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.