# Roles and guest access

> Owner, admin, member and guest, folder grants for guests, and prototype access modes.

Source: https://critlab.app/docs/enterprise/roles

critlab separates two kinds of people: **members** of a workspace, who hold a role and a seat, and **reviewers**, who open a share link and comment without an account. This page covers member roles, folder-scoped guests, and how each prototype's access mode decides who can open it.

## Roles

| Action | Owner | Admin | Member | Guest |
| --- | --- | --- | --- | --- |
| Upload and manage prototypes, change their access | ✓ | ✓ | ✓ | in granted folders, as editor |
| See the members list | ✓ | ✓ | ✓ | |
| Invite people, revoke invitations | ✓ | ✓ | | |
| Change a role, remove a member | ✓ | ✓ (not owners) | | |
| Grant and revoke a guest's folder access | ✓ | ✓ | | |
| Change workspace settings | ✓ | ✓ | | |
| Configure SSO, directory sync, storage | ✓ | | | |
| Leave the workspace | ✓ (not the last owner) | ✓ | ✓ | ✓ |

Only an owner can make someone an owner or change an owner's role. The last owner can never be demoted or removed, so a workspace always has someone who can hand it on. Every member, whatever the role, uses a seat; pending invitations reserve one too.

## Guests and folder grants

A **guest** sees only the folders explicitly granted to them, and everything inside those folders — the typical client of an agency, or a contractor on one product. Grants are inherited downward: a grant on `Acme` covers `Acme/Website`.

| | Viewer grant | Editor grant |
| --- | --- | --- |
| Open prototypes, read and write comments | ✓ | ✓ |
| Publish versions, create prototypes in the folder | | ✓ |
| Move prototypes within the grant, set status and description | | ✓ |
| Change access modes, delete prototypes, manage folders or members | | |

- When two grants overlap, the stronger one wins.
- Unfiled prototypes are never visible to guests.
- A guest asking for something outside their grants gets exactly what an outsider gets — "not found" — so folder names, which are often client names, never leak.
- Deleting a folder deletes the grants on it; its contents move up a level, out of the guest's reach.

Owners and admins grant folders from **Settings → Members**, from a folder's **Access…** dialog, or with `crit grant`. An invitation can carry folder grants, applied when it is accepted. Single sign-on and directory sync can assign the guest role from a group, but never folder grants.

## Prototype access modes

Each prototype has an access mode, and each workspace a default for new prototypes:

| Mode | Who can open the share link | Account needed |
| --- | --- | --- |
| Link | Anyone with the URL | No |
| Password | Anyone with the URL and the prototype's password | No |
| Members | Signed-in members who can reach the prototype's folder | Yes |

Members-only access is a Team and Enterprise feature (on self-hosted installs, part of the licence). With it, guests reach a members-only prototype only through a folder grant. In every mode the prototype itself is served from the sandbox through short-lived signed URLs, and never indexed.

## API keys

API keys act as the person who created them, with that person's role, plus scopes that limit what the key may do: `prototypes` (always), `workspace:write` (settings, members, SSO, SCIM, storage, domains), `billing:write` and `audit:read`. A scope never grants more than the person's role allows. API keys can only delete comments written by agents.