Roles and permissions

A role is a named bundle of permissions. Each person holds exactly one role — changing someone's access means replacing their role, not adding a second one.

Where to find it: Settings → People → 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 eight system roles. They can't be edited or deleted. Elaichi keeps their permissions in sync when the product adds new capabilities.

Six of them form a ladder — each rung can do everything the rung below it can, plus one more job:

Guest → Member → Team Admin → People Admin → Org Admin → Org Owner

Two more roles sit outside the ladder, for people who need one narrow slice of access. Both are free seats:

Permissions by built-in role

The six ladder roles:

The two free-seat roles, which only hold what their job needs:

Permission catalog

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

Four verbs repeat across the catalog, and they always mean the same thing:

• create — make your own, and manage what you made.
• share — decide who else can use the thing you made.
• view — see organization-wide settings of that kind. On connections, templates, and toolboxes it does not hand you other people's resources.
• manage — administer organization-wide settings of that kind. On connections, templates, and toolboxes it reaches only what you own or hold an edit share on.

Organization

Billing

Connectors

Connections

Templates

Toolboxes

Governance

Tool execution

Assistant

The in-app agent is not yet available to customer organizations, so this permission has no effect today. To drive Elaichi with AI, point your own AI client at the MCP endpoint — see How Elaichi connects to AI clients.

API tokens

SSO & identity

Logging

Notifications

Create a custom role

1. Open Settings → People → 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:

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:view.
• 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

• Each person holds exactly one role. Promoting someone replaces their role rather than adding to it.
• Changes apply immediately — including to people who are already signed in, and to API tokens or your organization's MCP endpoint when it runs 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.
• Guest, Billing Admin, and Auditor are free seats — they don't consume a billable seat.

Related

• Invite and manage people
• Organize people into teams
• Set connector and tool restrictions
• Provisioning members with SCIM