# Roles and permissions

> Source: https://elaichi.ai/docs/guides/members/roles/

A **role** is a named bundle of permissions. People can hold several roles at once — their effective access is the union of everything those roles allow.

**Where to find it:** **Members & Roles → Roles**

You need the **Manage roles** permission (`role:manage`) to create or edit custom roles. Built-in roles are always visible; only custom roles can be changed.

## Built-in roles

Every organization starts with five system roles. They can’t be edited or deleted. Elaichi keeps their permissions in sync when the product adds new capabilities.

| Role | Who it’s for | What it can do |
| --- | --- | --- |
| **Org Owner** | The people ultimately responsible for the workspace | Everything in the permission catalog. At least one member must always hold this role. |
| **Org Admin** | Day-to-day administrators | Everything in the permission catalog (same capabilities as Owner today). |
| **Team Admin** | Leads who run teams and tooling without owning org settings | Manage teams and members; work with connectors, connections, toolboxes, and MCP servers; use and approve the assistant. Cannot change org settings, roles, SSO, billing-related settings, restrictions, audit access, API tokens, or logging destinations. |
| **Member** | Default for new people (invites, domain join, and SCIM when no other role is mapped) | Browse connectors; create personal connections, toolboxes, and MCP servers; share toolboxes; use and approve the assistant. Cannot create shared (team/org) connections or manage other people’s resources. |
| **Viewer** | Read-only guests | Browse the connector catalog and use the assistant. Cannot connect accounts or change anything. |

:::callout{type="info"}
**Org Owner** and **Org Admin** currently grant the same permissions. Owner is reserved for future organization-level actions (such as deletion) and for the “last owner can’t leave” rule — keep at least one Owner even if you also use Admin.
:::

### Permissions by built-in role

| Permission | Owner | Admin | Team Admin | Member | Viewer |
| --- | :---: | :---: | :---: | :---: | :---: |
| `org:manage` | ✓ | ✓ | | | |
| `team:manage` | ✓ | ✓ | ✓ | | |
| `member:manage` | ✓ | ✓ | ✓ | | |
| `role:manage` | ✓ | ✓ | | | |
| `connector:read` | ✓ | ✓ | ✓ | ✓ | ✓ |
| `connector:create` | ✓ | ✓ | ✓ | | |
| `connector:share` | ✓ | ✓ | ✓ | | |
| `connection:create` | ✓ | ✓ | ✓ | ✓ | |
| `connection:create_shared` | ✓ | ✓ | ✓ | | |
| `connection:manage` | ✓ | ✓ | ✓ | | |
| `toolbox:create` | ✓ | ✓ | ✓ | ✓ | |
| `toolbox:share` | ✓ | ✓ | ✓ | ✓ | |
| `toolbox:manage` | ✓ | ✓ | ✓ | | |
| `mcp:create` | ✓ | ✓ | ✓ | ✓ | |
| `mcp:manage` | ✓ | ✓ | ✓ | ✓ | |
| `restriction:manage` | ✓ | ✓ | | | |
| `restriction:override` | ✓ | ✓ | | | |
| `audit:read` | ✓ | ✓ | | | |
| `api_token:manage` | ✓ | ✓ | | | |
| `sso:manage` | ✓ | ✓ | | | |
| `logging:manage` | ✓ | ✓ | | | |
| `assistant:use` | ✓ | ✓ | ✓ | ✓ | ✓ |
| `assistant:manage` | ✓ | ✓ | | | |
| `assistant:approve` | ✓ | ✓ | ✓ | ✓ | |

## Permission catalog

These are the permissions you can tick when creating a custom role. The role editor groups them the same way.

### Organization

| Permission | What it allows |
| --- | --- |
| `org:manage` | Edit the organization name, short URL name, logo, and verified domains. |

### People

| Permission | What it allows |
| --- | --- |
| `team:manage` | Create and edit teams, and manage who belongs to them. |
| `member:manage` | Invite people, change roles, and remove members. |
| `role:manage` | Create custom roles and choose which permissions they include. |

### Connectors

| Permission | What it allows |
| --- | --- |
| `connector:read` | View the connector catalog. |
| `connector:create` | Author custom connectors for the organization. |
| `connector:share` | Share custom connectors with teams or the whole organization. |

### Connections

| Permission | What it allows |
| --- | --- |
| `connection:create` | Connect accounts for personal (user-scoped) use. |
| `connection:create_shared` | Connect accounts owned by a team or the whole organization. |
| `connection:manage` | Reconnect or delete any connection in the organization. |

### Toolboxes

| Permission | What it allows |
| --- | --- |
| `toolbox:create` | Create toolboxes and add tools to them. |
| `toolbox:share` | Share toolboxes with members, teams, or the organization. |
| `toolbox:manage` | Edit or delete other members’ toolboxes. |

### MCP servers

| Permission | What it allows |
| --- | --- |
| `mcp:create` | Publish MCP endpoints from toolboxes. |
| `mcp:manage` | Edit, rotate, or revoke other members’ MCP endpoints. |

### Governance

| Permission | What it allows |
| --- | --- |
| `restriction:manage` | Limit which connectors and tools roles or members can use. |
| `restriction:override` | Bypass role-level restrictions when needed. |
| `audit:read` | See privileged actions across the organization. |

### Settings & security

| Permission | What it allows |
| --- | --- |
| `api_token:manage` | Create and revoke organization API tokens. |
| `sso:manage` | Configure SSO, SCIM tokens, and group-to-role mappings. |
| `logging:manage` | Forward organization events to your logging tools. |

### Assistant

| Permission | What it allows |
| --- | --- |
| `assistant:use` | Chat with the AI assistant and run approved actions. |
| `assistant:manage` | Configure provider keys, models, and assistant settings. |
| `assistant:approve` | Approve or reject write and destructive assistant actions. |

## Create a custom role

1. Open **Members & Roles → Roles**.
2. Choose **Create** (or edit an existing custom role).
3. Name it after the job, such as “Support lead” or “Read-only analyst”.
4. Tick the permissions from the catalog above.
5. Save. Assign the role to people from **People**, or map it from SCIM groups under **Settings → SSO**.

**You'll know it worked when:** People with that role see the screens and actions you intended, and nothing more.

## How roles combine with other access

Roles are only one layer:

```mermaid title="What must line up for a tool to run"
flowchart TD
  Ask["Agent asks for a tool"] --> Role["Role permissions<br/>may they use MCP / connectors?"]
  Role --> Share["Resource share<br/>view / use / edit on toolbox"]
  Share --> Restrict["Restrictions<br/>connector or tool allow/block"]
  Restrict --> Run["Tool runs<br/>through their connections"]
```

- **Roles** decide which *actions* someone may take in the app (create a connection, manage SSO, and so on).
- **Restrictions** can still hide specific connectors or tools from a role, even if the role has `connector:read`.
- **Sharing** on a toolbox or custom connector decides whether someone can view, use, or edit that particular resource.

Someone needs the permission *and* any required share *and* to clear restrictions before a tool is actually usable through MCP.

## Good to know

- People can hold multiple roles; permissions add up.
- Changes apply immediately — including to people who are already signed in, and to API tokens or MCP servers that run as them.
- Built-in roles can’t be edited. Copy the idea into a custom role instead.
- The last **Org Owner** can’t be removed or demoted until someone else is an Owner.
- New joiners (invite, verified-domain join, or SCIM without a group mapping) get **Member** by default unless you choose another role.

:::callout{type="tip"}
Start from **Member** or **Viewer** and add only what the job needs. It’s easier to grant one more permission later than to unwind a broad Admin assignment.
:::

## Related

- [Invite and manage people](/guides/members/invite-and-manage-people)
- [Organize people into teams](/guides/members/teams)
- [Set connector and tool restrictions](/guides/governance/set-restrictions)
- [Provisioning members with SCIM](/guides/sso/scim-provisioning)