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

# User Roles and Permissions in Scrubbe Explained

> Understand Scrubbe's role-based access model, what each role can do, how to assign roles when inviting team members, and how the CUSTOMER role works.

Scrubbe uses role-based access control (RBAC) to define what each team member can see and do inside the platform. Every user is assigned one or more roles when they are invited to your organization. Roles range from full administrative access down to read-only observation, and a separate `CUSTOMER` role grants access only to the self-service customer portal. Choosing the right role for each team member keeps your incident data secure and your workflows predictable.

## User roles

| Role          | Operational access                                                                                                                                                       |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `SUPER_ADMIN` | Unrestricted access to all features, settings, and data across the platform. Reserved for platform owners and system administrators.                                     |
| `ADMIN`       | Administrative access including user management, blog posts, and job listings. Appropriate for operations leads who need full organizational visibility.                 |
| `MANAGER`     | Can manage team members and incident records. Appropriate for engineering managers and team leads overseeing on-call rotations and escalations.                          |
| `ENGINEER`    | Can create, update, and resolve incidents. The standard role for engineers who actively respond to incidents and contribute to post-mortems.                             |
| `RESPONDER`   | Can acknowledge and resolve incidents that are assigned to them. A narrower version of `ENGINEER` suitable for on-call responders who do not need to create new tickets. |
| `VIEWER`      | Read-only access across all incident data and reports. Appropriate for stakeholders, product managers, or auditors who need visibility without write access.             |
| `CUSTOMER`    | Access only to the customer self-service portal. This role is for external users who submit and track their own incidents — not for internal team members.               |

<Note>
  A user's `roles` field is an array, so a single account can hold multiple roles. In practice, most team members are assigned a single role that reflects their primary function.
</Note>

## Account types

In addition to roles, each account has a type that governs which parts of the platform are available:

| Account type | Description                                                                                                                        |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| `DEVELOPER`  | Individual developer account. Suitable for solo users or developers evaluating the platform.                                       |
| `BUSINESS`   | Organization account. Required for team features including on-call scheduling, SLA policies, and multi-member incident management. |

## Inviting team members

Use `POST /api/v1/business/send-invite` to invite a new team member and assign their role in the same request:

```http theme={null}
POST /api/v1/business/send-invite
```

```json theme={null}
{
  "email": "teammate@example.com",
  "role": "ENGINEER",
  "accessPermissions": ["incidents", "postmortems"],
  "level": "Senior"
}
```

| Field               | Description                                                                                         |
| ------------------- | --------------------------------------------------------------------------------------------------- |
| `email`             | Email address of the person being invited                                                           |
| `role`              | One of the roles listed above                                                                       |
| `accessPermissions` | Array of feature areas the user can access — valid values include `"incidents"` and `"postmortems"` |
| `level`             | Optional seniority label (e.g. `"Senior"`, `"Lead"`) used for display and escalation context        |

The invite recipient receives an email with a token-based link. They accept it via `POST /api/v1/business/accept-invite`, at which point their account is created with the assigned role and permissions.

## Accepting an invite

To decode an invite token before accepting it (useful for pre-filling a sign-up form):

```http theme={null}
POST /api/v1/business/decode-invite
```

To accept the invite and create the account:

```http theme={null}
POST /api/v1/business/accept-invite
```

## The CUSTOMER role

The `CUSTOMER` role is distinct from all team roles. Users with this role authenticate through the customer portal (`/api/v1/customer`) and can only submit incidents, view their own incident history, and read resolution summaries published to the knowledge base. They cannot access your organization's internal incident dashboard, SLA data, or team settings.

Customer portal users register separately via `POST /api/v1/customer/register` and log in via `POST /api/v1/customer/login`. They are not invited through the team invite flow.

<Tip>
  If you want an external stakeholder to have read-only visibility into your internal incident data, use the `VIEWER` role and send them a standard team invite — not the customer portal. Reserve the `CUSTOMER` role for end-users of your product who are reporting issues they have experienced.
</Tip>

## Listing your team

Retrieve all current members and their roles with:

```http theme={null}
GET /api/v1/business/get_members
```

This endpoint returns each member's ID, email, assigned roles, access permissions, and account status. Use the returned user IDs when creating on-call assignments or filtering incident analytics by assignee.