> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dacard.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Role-based access control in Dacard.ai

# Roles & Permissions

Dacard.ai uses hierarchical role-based access control (RBAC). Each user is assigned exactly one role, and higher roles inherit all permissions from lower roles.

## Six roles

> **Member**
>
> **Level 10**, Product Manager / ProdOps
>
> Score products and view own results.

> **Lead**
>
> **Level 20**, Product / ProdOps Lead
>
> View team scores, create products, access Operations and Lifecycle reports.

> **Executive**
>
> **Level 30**, Executive / Investor
>
> Portfolio-level reporting, billing access, read-heavy role.

> **Admin**
>
> **Level 40**, Account Admin
>
> Full account management: members, products, settings.

> **Super Admin**
>
> **Level 50**, Super Admin
>
> Cross-account visibility. View all scores, manage multiple accounts.

> **Dacard Admin**
>
> **Level 100**, Platform Operator
>
> Full system access: impersonation, PQL signals, analytics.

> [!NOTE]
>
> Roles are hierarchical. An `admin` (level 40) automatically inherits all permissions from `member` (10), `lead` (20), and `executive` (30).

## Permission matrix

**Scoring**

| Permission | member | lead | executive | admin | super\_admin | dacard\_admin |
| - | - | - | - | - | - | - |
| Create scores | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| View own scores | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| View team scores | | ✅ | ✅ | ✅ | ✅ | ✅ |
| View all scores | | | | | ✅ | ✅ |
| Delete scores | | | | ✅ | ✅ | ✅ |

**Products**

| Permission | member | lead | executive | admin | super\_admin | dacard\_admin |
| - | - | - | - | - | - | - |
| View team products | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create products | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Edit products | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Delete products | | | | ✅ | ✅ | ✅ |

**Reports**

| Permission | member | lead | executive | admin | super\_admin | dacard\_admin |
| - | - | - | - | - | - | - |
| Maturity reports | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Operations reports | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Lifecycle reports | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Suite intelligence | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Portfolio reports | | | ✅ | ✅ | ✅ | ✅ |

**Account**

| Permission | member | lead | executive | admin | super\_admin | dacard\_admin |
| - | - | - | - | - | - | - |
| View account | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Use DAC copilot | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Manage integrations | | ✅ | ✅ | ✅ | ✅ | ✅ |
| Manage billing | | | ✅ | ✅ | ✅ | ✅ |
| Edit account settings | | | | ✅ | ✅ | ✅ |
| Manage members | | | | ✅ | ✅ | ✅ |

**Platform Admin**

| Permission | member | lead | executive | admin | super\_admin | dacard\_admin |
| - | - | - | - | - | - | - |
| Manage all accounts | | | | | ✅ | ✅ |
| Impersonate users | | | | | | ✅ |
| System settings | | | | | | ✅ |
| View PQL signals | | | | | | ✅ |
| View analytics | | | | | | ✅ |

## Role assignment

Roles are assigned during onboarding based on the user's self-reported title:

| Title pattern | Assigned role |
| - | - |
| Founder, CEO, Investor, Board | `executive` |
| CPO, CTO, VP, Director, Head of, Lead | `lead` |
| All others (PM, Engineer, etc.) | `member` |

Account admins can change any member's role up to their own level via `PATCH /api/account/members`. Admins can assign `member`, `lead`, `executive`, or `admin`. Only `dacard_admin` can assign `super_admin` or `dacard_admin`.

## How roles are stored

Roles are stored in two places for resilience:

1. **Clerk publicMetadata**, fast path, read from session claims (no DB call)
2. **Database**, source of truth, synced to Clerk on role change

When an admin changes a role, the API updates the database first, then syncs to Clerk metadata. The user's next session will reflect the new role.

## API enforcement

All protected endpoints check the user's role before executing. Insufficient permissions return:

```json theme={null}
{
  "error": "Forbidden: insufficient permissions"
}
```

See [Authentication](https://docs.dacard.ai/authentication.md) for details on how sessions are established.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.