Roles and permissions | Elaichi Documentation

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.

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

Open Members & Roles → Roles.
Choose Create (or edit an existing custom role).
Name it after the job, such as “Support lead” or “Read-only analyst”.
Tick the permissions from the catalog above.
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:

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.

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.