Admin Settings → Users is your people directory: every account, their role, their groups, and their activity hooks.
The user list
The list shows each account with name, email, role, status and activity. Row actions:
| Action | Effect |
|---|---|
| Add User | Create an account — name, email, role, and initial password (or rely on your identity provider). |
| Edit User | Change name, email, role, groups and status. |
| Deactivate / Activate | Deactivated accounts cannot sign in — the correct response to leavers and suspensions. Data is retained. |
| Delete User | Removes the account. Prefer deactivation unless policy requires deletion. |
| View user chats | Administrators can see a user's chat list where policy permits — intended for support and investigations. Handle with care and disclose it in your acceptable-use policy. |
| Reset password | Issue a temporary password for a locked-out user. |
| Search / filter | Find accounts quickly in large directories. |
Roles
Every account has one role:
| Role | Can do |
|---|---|
| Admin | Everything, including this page. Grant sparingly. |
| Power user | Standard capabilities plus creator features (models, knowledge, workflows, templates) as permissions allow. |
| User | Day-to-day chat, documents, media within their group permissions. |
| Pending | Created but not yet active (for example awaiting approval flows). |
The Default role applies to self-registered accounts; set it to the lowest acceptable level.
Groups
Groups organise people for access control — and they are how most capability decisions scale:
| Action | Notes |
|---|---|
| Add Group | Name the group (team, department, project) and optionally its description. |
| Edit Group | Rename, change description, change user membership. |
| Assign permissions | Each group's feature access — the Permissions page. |
| Assign knowledge and models | Groups control who sees which knowledge bases and models. |
| Remove Group | Members fall back to default permissions until regrouped. |
Group design that scales
- Mirror your organisation lightly — a group per department that needs distinct access, plus cross-cutting groups like
AI-pilotsordata-team. - Permissions follow groups, never individuals — it keeps audits simple.
- New joiners land in one base group; extra access is added deliberately.
Directory-sourced accounts
With directory authentication enabled, accounts sign in with corporate credentials. IntraLLM still manages role and group assignment locally; leaver deactivation should ride your directory's disabled accounts.