Skip to main content

​
Overview

Nadoo AI implements a two-level role-based access control (RBAC) system. System roles govern platform-wide capabilities, while workspace roles control what a user can do within a specific workspace. Together they ensure that every user has the minimum privileges needed for their tasks.

System Roles

Platform-level roles that determine administrative access across the entire Nadoo AI instance.

Workspace Roles

Per-workspace roles that control resource-level permissions within a single workspace.

​
System Roles

System roles are assigned at the platform level and determine a user’s global capabilities.
RolePriorityDescription
Super Admin100Full control over the entire platform. Can manage all users, workspaces, and system settings.
Admin80Can manage users, create and update applications, knowledge bases, models, tools, and workspaces. Cannot access super-admin-only settings.
User50Standard platform user. Can read applications, knowledge bases, models, tools, and workspaces they have access to.
Guest10Minimal read-only access. Can view applications and knowledge bases only.
Every new account is assigned the User system role by default. Only an existing Super Admin can promote a user to Admin or Super Admin.

​
Workspace Roles

Within each workspace, members are assigned one of three roles that govern resource-level permissions.
RolePriorityDescription
Owner100Full control over the workspace, including member management, all resources, and workspace deletion.
Admin80Can manage all resources (applications, knowledge bases, models, tools, workflows) and workspace members. Cannot delete the workspace or transfer ownership.
Member50Can read, create, and update most resources. Cannot delete resources, manage members, or change workspace settings.

​
Permission Matrix

The table below shows exactly which actions each workspace role can perform.
ActionOwnerAdminMember
Create applicationsYesYesYes
Update applicationsYesYesYes
Delete applicationsYesYesNo
Execute applicationsYesYesYes
Create knowledge basesYesYesYes
Update knowledge basesYesYesYes
Delete knowledge basesYesYesNo
Register modelsYesYesYes
Update modelsYesYesNo
Delete modelsYesYesNo
Create toolsYesYesYes
Delete toolsYesYesNo
Create workflowsYesYesYes
Update workflowsYesYesYes
Delete workflowsYesYesNo
Manage membersYesYesNo
Manage workspace rolesYesYesNo
Update workspace settingsYesYesNo
Delete workspaceYesNoNo
The Owner role is automatically assigned to the user who creates the workspace. Ownership transfer is not available through the UI — contact a Super Admin if you need to change the workspace owner.

​
Permission Groups

Permissions are organized into groups that map to major platform features. Each permission combines a group with an action (Create, Read, Update, Delete, Execute, Export, Import, Share, or Manage).
Controls access to applications, their configurations, chat users, and chat logs. Sub-groups include:
  • APPLICATION — Core CRUD operations
  • APPLICATION_OVERVIEW — Dashboard and analytics
  • APPLICATION_ACCESS — Access control settings
  • APPLICATION_CHAT_USER — Chat user management
  • APPLICATION_CHAT_LOG — Conversation history
Controls access to knowledge bases, documents, and search features. Sub-groups include:
  • KNOWLEDGE — Core CRUD operations
  • KNOWLEDGE_DOCUMENT — Document upload and management
  • KNOWLEDGE_PROBLEM — Problem detection and quality
  • KNOWLEDGE_HIT_TEST — Search testing and evaluation
  • MODEL — AI model provider registration and configuration
  • TOOL — Custom tool creation and management
  • WORKFLOW — Workflow creation, editing, and execution
  • WORKSPACE — Workspace settings and configuration
  • WORKSPACE_ROLE — Role assignment within a workspace
  • USER_MANAGEMENT — Platform-level user administration
  • EMAIL_SETTING, DISPLAY_SETTINGS, LOGIN_AUTH — System configuration
  • OPERATION_LOG — Audit log access

​
Inviting Users to a Workspace

Workspace Owners and Admins can invite new members through the API or the workspace settings page.
1

Navigate to Workspace Settings

Open Workspace Settings > Members in the Nadoo AI dashboard, or use the API directly.
2

Add a Member

Provide the user’s ID and the desired role. Via the API:
POST /api/v1/workspaces/{workspace_id}/members
Authorization: Bearer {access-token}
Content-Type: application/json

{
  "user_id": "a1b2c3d4-...",
  "role": "member"
}
Valid role values: owner, admin, member.
3

Verify Membership

List workspace members to confirm the invitation was accepted:
GET /api/v1/workspaces/{workspace_id}/members
Authorization: Bearer {access-token}

​
Changing a Member’s Role

Owners and Admins can update a member’s role at any time: 
PUT /api/v1/workspaces/{workspace_id}/members/{user_id}/role
Authorization: Bearer {access-token}
Content-Type: application/json

{
  "role": "admin"
}

​
Removing a Member

DELETE /api/v1/workspaces/{workspace_id}/members/{user_id}
Authorization: Bearer {access-token}
Removing a member revokes their access to all workspace resources immediately. Their previously created resources remain in the workspace.

​
User Profile & Authentication

Each user account stores the following profile information:
FieldDescription
emailUnique email address (used for login)
usernameOptional unique display name
full_nameUser’s display name
avatar_urlProfile picture URL
languagePreferred UI language (default: en)
timezonePreferred timezone (default: UTC)
is_verifiedWhether the email has been verified
is_activeWhether the account is enabled

​
Social Login

Nadoo AI supports social account linking for streamlined authentication. Users can connect their accounts from supported OAuth providers (e.g., Google, GitHub) to enable single-click sign-in.
Enterprise deployments can enable SSO/OIDC integration for centralized identity management. See the Self-Hosting section for SSO configuration details.

​
Best Practices

Assign the Member role by default. Only promote users to Admin or Owner when they genuinely need elevated access. This limits the blast radius of compromised credentials.
Use the audit log (GET /api/v1/system/audit-logs) to review role assignments. Look for unexpected privilege escalations.
Create separate workspaces for different teams or projects rather than sharing a single workspace with complex permission overrides.
Set EMAIL_VERIFICATION_REQUIRED=true in your environment to ensure all users verify their email before gaining access to workspace resources.