# Users and roles

**You'll need:** an administrative role. **Administration → Users** and
**Administration → Roles**.

## Users

The user list shows everyone in the workspace with their roles, last login and status.

Opening a person gives you:

| | |
|---|---|
| **Roles** | Assign and unassign. |
| **Custom Permissions** | Grant a single permission directly, without creating a role for it. |
| **Combined Permissions** | What the person actually holds: roles plus custom grants, after the plan is applied. Read this rather than inferring it. |
| **Reset password** | Sends them a reset email. You cannot see or set their password. |
| **Deactivate** | Ends access while keeping their history. |

Deactivate rather than delete for anyone who did work in the workspace. Deleting is for
accounts created in error.

## Roles

A role is a named set of permissions. The role editor groups permissions by area in a
searchable accordion, with a summary at the top reporting whether the role has **no
admin privileges**, **some admin privileges** or **full admin privileges**.

Check that summary before saving. It is easy to grant one innocuous-looking
administrative permission and turn a content role into an admin role.

Each role also shows how many permissions it holds and how many people hold it, which
makes unused roles easy to find.

### System roles

The thirteen roles a workspace starts with are ordinary records that you can edit or
delete. Some are marked **System Role**, or are managed at the product level and cannot
be edited here; those are maintained for you.

### Build your own

Start from the closest built-in role, copy it, and narrow it. Building from an empty
role means discovering each missing permission through a support request.

Name roles for who holds them rather than what they do: "Agency Photographer" is clearer
than "Media Upload + Album Add".

## Custom permissions

When one person needs one extra permission, a whole role is unnecessary. **Custom
Permissions** on the user record grants it directly.

Use this sparingly. Permissions granted this way do not appear in the roles list, so
"why can Dana do that?" becomes a question only this screen can answer. If you grant the
same custom permission three times, make it a role.

## Who changed what

**Administration → History** records every change to users and roles with the before and
after of the record, who made it, and when. **Administration → Access Log** records the
requests themselves.

Between them, "who granted this access, and when" always has an answer. See [audit and
history](/guide/admin/audit).