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.
