# Roles & user groups

> How the four fixed roles combine with user groups - site-scoped teams that keep work-request notifications and assignee suggestions relevant.

Source: https://app.assetlab.ca/docs/manage/roles-and-permissions

Access in AssetLab is two questions with two separate answers. **Roles** decide what someone can *do* - the [four-role hierarchy](/docs/start/roles-and-access) 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](/docs/reference/roles-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](/docs/cmms/work-requests) 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](/docs/cmms/work-orders) 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](/docs/asset-management/documents) 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](/docs/manage/org-settings).

## 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](/docs/start/roles-and-access).
- **Not the portal boundary.** [Requester isolation](/docs/cmms/requester-portal) is structural; requester groups organize requesters, they don't expand their access.
- **Not cross-organization.** Groups, like everything else, live inside one organization.