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

# Users and Roles

> Add people to an account, assign one of four roles, and link their messaging identities.

An account has members. Each member holds exactly one **account role**, and may
additionally hold per-resource grants.

Add and edit them in the Portal under **Settings → Users**.

## The four roles

| Role | What it can do |
| - | - |
| **Owner** | Everything |
| **Admin** | Everything |
| **Member** | Everything except delete |
| **Restricted** | Nothing by role — only what per-resource grants allow |

That is the whole model. There is no separate "Developer" or "Viewer" role.

Two consequences worth knowing:

* **Restricted is for machine principals, not people.** Inviting a teammate
  offers Member, Admin, or Owner; Restricted is rejected for a human member. It
  is the role an API key's service principal carries, where access comes
  entirely from per-resource grants.
* **Resolving an approval gate is never implied by a role.** Not even Owner. The
  `ResolveGate` authority is grantable on an **agent** and only ever arrives as an
  explicit grant. Account admins and owners can still resolve gates they
  encounter through the normal approval surfaces; the grant exists so a non-human
  caller can be delegated that authority.

Some Settings views are visible to Admin and Owner only — Workspace General,
Features, Limits, and account-wide Autonomy. Users, API Keys, and Connected Apps
are hidden from Restricted members.

## Adding a member

Create the user from **Settings → Users**. If that email already has a principal
on the platform, the membership is added immediately. Otherwise it records a
pending invitation: the person signs in to the Portal with that email, and on
first successful sign-in the platform materialises their principal and every
membership they were invited to, atomically.

Invited users are not waitlist-gated — an admin started the process, not a
self-serve signup.

Inviting and changing roles requires Admin or Owner, and only an Owner manages
other Owners. Members can see the roster without being able to invite.

## Deactivating a member

A user's detail view has an active/inactive switch. Deactivating blocks
authentication without deleting the record or its history.

## Linked platforms

Each user's detail page carries a **Linked Platforms** card — the external
messaging identities that person can use to reach agents.

| Platform | Field | Example |
| - | - | - |
| Telegram | Telegram User ID | `123456789` |
| Slack | Slack Member ID | `U01ABC23DEF` |
| SMS | Phone number | `+14155551234` |

Telegram and Slack link immediately. **SMS requires a second step**: the platform
sends a 6-digit code to the number and the user enters it to verify. Identities
show as Verified or Pending.

## Per-user tool policy

A user's detail page also carries a **Policies** card. This is where an admin
disables specific tools for that one person, on top of the account-wide policy.
See [Autonomy and approvals](/docs/run/platform/autonomy-and-approvals).

## Next

* [API keys](/docs/run/platform/api-keys) — non-human access
* [Autonomy and approvals](/docs/run/platform/autonomy-and-approvals)


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