Cheatsheet

Scope	Role	Maps To	Level of Control
Organization	Owner	COO / VP Ops / Director CX	Full control including billing
	Admin	Head of CS / CX	Full operational control (no billing)
	Billing	Finance Team	Financial visibility only
	Member	Everyone	Minimal user access, default
	Viewer	CEO, Executive, Auditor	Read-only
Project	Owner	Project Lead / CX Lead	Full project control
	Contributor	Support Manager / Engagement Manager	Operate, edit, redeploy
	Member	Support Agent / Analyst	Operate, label, triage
	Viewer	Client / QA / Stakeholder	Read-only project visibility

Organization-Level Roles

Role	Typical Title(s) in a Service Organization	Functional Analogy
Organization Owner (`o_owner`)	COO, VP Operations, Director of Customer Experience (CX)	Senior operations leader overseeing all company-wide systems, billing, compliance, and account-level management. Owns contracts, organization settings, and access governance.
Organization Admin (`o_admin`)	Head of Customer Success (CS), Head of Customer Experience (CX)	Manages customer delivery teams and organization resources. Full operational control except for billing and account termination.
Billing (`o_billing`)	Finance Team, Controller, Procurement Lead	Handles invoices, usage tracking, renewals, and cost approvals. Limited to financial visibility and read-only project information.
Organization Member (`o_member`)	Everyone with limited access to one or more projects — e.g., CSMs, Project Managers, Support Managers, Agents	Standard employee or leader working across multiple projects. Can read and manage project memberships but not change billing or org policies.
Organization Viewer (`o_viewer`)	Executive Leadership, CEO, VP Strategy, External Auditor	Read-only visibility across the organization for reporting, reviews, or oversight. Cannot change settings or data.

Project-Level Roles

Role	Typical Title(s) in a Service Organization	Functional Analogy
Project Owner (`p_owner`)	Engagement Manager, Service Delivery Lead, CX Program Manager	End-to-end accountable for a project’s success. Can deploy models, manage integrations, and assign roles within the project.
Project Contributor (`p_contributor`)	Support Manager, Project Lead, Senior CSM / CX Lead	Operates and improves the deployed AI systems. Can edit knowledge, debug, run evaluations, and redeploy—trusted to change live behavior safely.
Project Member (`p_member`)	Support Agent, CX Associate, Operations Analyst, Quality Assurance	Works in day-to-day operations: handles conversations, labeling, data triage. Can’t modify knowledge or deploy models.
Project Viewer (`p_viewer`)	Executives, Account Executive	Read-only access to performance dashboards, transcripts, and reports. For oversight, validation, or executive review.

Custom Roles

We support custom roles on project level.

Detailed Information

<aside> 💡

Organizations have one or more projects. Permissions are defined on organization level and on project level. The two scoping mechanisms are important. Organizational roles and permissions given through organizational roles are automatically inherited in the project. There's no notion of explicitly excluding permissions per project instead, give less permission on organizational level and then grant and permission on a project level. We also chose this approach because if scales better. If a customer adds another project, every team member would have access by default and would require updated settings for every single team member in their organization. Instead we opt for an explicit inclusion in projects, which is also easier to understand.

</aside>

Overview

Every user has one organization role and upto one role per project. Organization roles are prefixed with o_. Rroject roles with p_ for buildin roles and pc_ for custom roles.
Every user can have at max 50 project roles.
Custom Roles are always project scoped. You cannot create organization scoped custom roles.
If any role of a user allows an action, the action can be performed (i.e. no project role, but Organization Admin).
You cannot edit your own role. The “root” user in every organization is the Organization Owner.
By default, users are organization members that have no permissions*. This means admins and owners must create projects and then set a member as Project Owner. They can then manage that project, invite users and act.

Invite users

Organization Owners, Organization Admins and Project Owners can invite users. If a user is added to a project, they will join the conversation, but have no access role.
Only the Organization Owern can remove users from the organization. We might change this in the future.

*no permissions = Means users will only be able to list all projects in an organization, and view all other members and roles in the organization. They are not able to access them (only project:read permission, none of the included entities).