# Users & invitations

> Inviting people, assigning roles, handling departures, and keeping the user list an asset instead of a liability.

Source: https://app.assetlab.ca/docs/manage/users-and-invitations

User management lives under **Settings → Users** (Administrator only). AssetLab authenticates by **email one-time passcode** - no passwords exist to be phished, reused, or reset.

**Requesters have their own tab** - **Settings → Requesters**. The Users tab shows only billable members (Administrator, Manager, Staff); portal users live on the Requesters tab, and Requesters aren't billable seats.

## Inviting users

1. **Settings → Users → Invite**.
2. Enter the email and pick a [role](/docs/start/roles-and-access) - Administrator, Manager, Staff, or Requester.
3. The invitee receives an email; accepting lands them in your organization at that role.

Invitations that sit unaccepted can be **revoked** from the same screen; to try again, revoke and send a fresh invitation.

> [!tip] Invite with the lowest plausible role. Promotion is one click; the reverse conversation is awkward.

### Bulk onboarding

Rolling out to a large group (every custodian, every tenant contact)? Invite in waves and pair each wave with the one workflow they need - Requesters need only "here's how you report a problem" (or just a [QR code on the wall](/docs/asset-management/qr-codes)).

## Changing roles

Select the user, change the role, done - takes effect on their next page load. When someone changes districts or trades rather than jobs, update their [user group](/docs/manage/roles-and-permissions) instead - the role stays, the notification scoping follows them.

Two guardrails apply:

- **The last Administrator can't be demoted.** At least one Administrator must always remain.
- **Promoting a Requester needs a free seat.** Requesters aren't billable; moving one to Staff, Manager, or Administrator is blocked at your seat limit until a billable user is removed.

## Workspace scoping

Each Manager or Staff member on the Users tab has a **Workspace** column: the full app (default), **facilities only**, or **infrastructure only**. It trims which module a member sees - an infrastructure-only member gets no facilities surfaces and vice versa. It's a declutter tool layered on top of the [role](/docs/start/roles-and-access), not a security boundary, and Administrators always see everything.

## Departures

**Remove** the user from the organization (there's no separate "deactivate" state):

- Their access ends immediately.
- Their history - completed work orders, comments, assessments - remains attributed and intact, which audits and warranty claims will thank you for.
- Reassign their open work from the work order list (filter by assignee).

If they also held an [API key](/docs/manage/api-keys) (for AI or scripts), revoke it in the same pass - the offboarding checklist is: remove, reassign, revoke.

## Several organizations, one person

A consultant or shared-services manager can belong to multiple organizations with a different role in each, switching from the profile menu. Each organization's Administrators control only their own membership - there's no cross-organization visibility.

## Auditing the roster

Quarterly, skim the user list with three questions:

1. Anyone who's left the organization? → remove.
2. Anyone with a role above their current job? → downgrade.
3. Administrators still limited to the few who need it? → the answer should be yes.