> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Users and roles

> Manage user accounts, roles, and platform-wide access in OASM

The **Users** section is where you manage the accounts that can sign in to OASM. User management is platform-wide: accounts exist once and can then be added to any number of [workspaces](/workspace), where their access is controlled by [permission groups](/members).

This separation is important:

* **Roles** determine what a user can do across the whole platform.
* **Permission groups** determine what a member can do inside a specific workspace.

## The Admin area

Platform-wide administration lives in a dedicated **Admin** area (`/admin`), separate from the workspace console and from **Settings**. It has its own sidebar:

| Sidebar group | Page | Path | Purpose |
| - | - | - | - |
| **Platform** | Users | `/admin/users` | Manage user accounts across the platform |
| **System** | [Brand name and logo](/brand-name-and-logo) | `/admin/brand` | Set the platform name and logo |
| **System** | About | `/admin/about` | Version, updates, and license information |

To open it, click your avatar at the bottom of the sidebar and choose **Admin** from the user menu. Opening `/admin` lands on **Users**.

> [!NOTE]
>
> The **Admin** menu entry is shown only to users with the platform **Admin** role. Anyone else who opens an `/admin` URL directly is redirected to the dashboard, and signed-out visitors are sent to the login page.

### About

The **About** page shows the running version and checks it against the latest release:

* **Up to date** — *"You are running the latest version."*
* **Update available** — names the newer version and its release date, with a **View release** link to GitHub. When release notes are available, a collapsible **Release notes** card shows them.
* **Unknown** — *"Could not check for updates."* (for example when the instance has no outbound internet access).

Below that are links to the **Source code**, **Report an issue**, and the **License** (GPL-3.0).

## Roles

OASM defines three platform-wide roles. A role affects what a user can do across the console.

| Role | Description |
| - | - |
| **Admin** | Full access to the platform, including user management |
| **User** | Standard workspace member with access to the workspaces they belong to |
| **Bot** | Machine or service account used for automated access |

> **When should I use the bot role?**
>
> Use the **Bot** role for machine and service accounts that need automated access, for example workers that pull scan jobs or API clients. Bot accounts are not tied to a human and are typically combined with the workspace [API key](/api-keys).

## List users

**1. Navigate to Users**

Open the user menu, choose **Admin**, then select **Users** under **Platform**.

**2. Browse the table**

The table lists **Name**, **Email**, **Role**, and **Status** for every account.

## Create a new user

**1. Click Add**

The **Add** button opens the creation dialog.

**2. Enter the account details**

Fill in **Name**, **Email**, and **Password**. The password must be at least **8 characters**.

**3. Select a role**

Choose either **User** or **Admin** from the role options.

**4. Create the user**

Submit the form. The new user can sign in immediately after creation.

## View user details

Click a user in the list to open the detail panel on the right, which contains two tabs:

* **Overview** — the user's account information and status.
* **Raw JSON** — the underlying account record, useful for troubleshooting.

From the detail panel you can edit the user's **name**, **email**, or **password** inline (pencil icon), change their **role**, or **Ban user** / **Unban user**.

## Change a user's role

Roles are changed from the user detail panel. Select a new role from the dropdown — the change takes effect immediately. Changing a user to **Admin** grants full platform access, including user management, so assign this role deliberately.

## Ban a user

Banned users **cannot sign in** to OASM and are marked **Banned** in the user list. Banning does not delete the account or its history, which makes it the recommended way to remove access while preserving auditability. To restore access, open the user and click **Unban user**.

> [!NOTE]
>
> There is **no delete user** option in OASM. To permanently remove access, ban the user instead. If you need to preserve a record of actions for compliance, see the [audit log](/audit-log).

## Best practices

* Assign the **Admin** role only to users who manage the platform — admin includes user management and full access.
* Use the **User** role for regular members and control workspace access through [permission groups](/members).
* Use the **Bot** role for automated access instead of sharing human credentials.
* Enforce passwords of 8 characters or more; the console enforces this minimum at creation.
* Ban users who leave the team or no longer require access instead of leaving stale accounts active.

## Related

> **[Brand name and logo](/brand-name-and-logo)**
>
> Customize the platform name and logo from the Admin area

> **[Workspace](/workspace)**
>
> Understand the isolated tenants users work inside

> **[Members](/members)**
>
> Manage members, invitations, and permission groups within a workspace

> **[API keys](/api-keys)**
>
> Use workspace API keys for automated and bot access

> **[Audit log](/audit-log)**
>
> Review account and workspace activity for compliance


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.