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

# Role-Based Access Control

> Control who can access which tools and systems with binary allowlists

<Info>
  **Enterprise Feature** — RBAC is available on superglue Enterprise plans. [Contact
  us](https://cal.com/superglue/superglue-demo) to learn more.
</Info>

Role-Based Access Control (RBAC) lets you define **roles** that control which tools and systems users can access. Roles can be assigned to organization members, giving you focused control over your integration layer.

## Core Concepts

### Base Roles

Every user has exactly one **base role**. superglue ships with two base roles:

| Base role  | Description                                                                                                              |
| ---------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Admin**  | Full access to everything. Bypasses RBAC checks. Cannot be edited.                                                       |
| **Member** | Default for organization members. Starts with access to all tools and systems. Tool and system allowlists can narrow it. |

### Custom Roles

You can create **custom roles** for specific use cases, such as a Sales Team role with access to CRM tools and systems. Custom roles are fully editable and can be assigned on top of a user's base role.

## Allowlists

Every role defines two binary allowlists:

* **Tools** — which saved tools the role can run
* **Systems** — which systems the role can access

Each allowlist supports two modes:

* `"ALL"` — every current and future resource is allowed
* Specific list — only listed resource IDs are allowed

```json theme={null}
{
  "name": "Sales Team",
  "tools": ["get-contacts", "search-deals", "update-deal"],
  "systems": ["salesforce", "hubspot"]
}
```

If a tool or system is not listed, it is denied. System access is binary by system ID: listed means allowed, omitted means denied.

## Tool And System Dependencies

Tool and system allowlists are intentionally entangled:

* A tool is effectively visible and runnable only when the user has access to the tool **and** every system referenced by the tool's request steps.
* Granting a tool without its required systems means the tool may still be hidden or blocked.
* `systems: "ALL"` satisfies every tool system dependency.

## Multi-Role Evaluation

Users can have multiple roles: one base role plus any number of custom and personal roles. Resolution is union:

| Layer   | Semantics                                             |
| ------- | ----------------------------------------------------- |
| Tools   | If any role allows a tool, the tool ID is allowed     |
| Systems | If any role allows a system, the system ID is allowed |

Roles can add access but cannot remove access granted by another assigned role.

## Personal Roles

Every user can have a **personal role**: a per-user allowlist that grants individual access on top of base and custom roles.

* Each user has at most one personal role
* Personal role allowlists are unioned with the user's other roles
* Admins can edit personal roles to grant or revoke direct personal access to tools and systems
* Use case: giving a single team member access to a sensitive system without creating a shared role

Manage personal roles via the **Personal Roles** tab in Access Rules, or the REST API (`POST /v1/users/:userId/personal-role`).

## Auto-Grant On Resource Creation

When a user creates a new tool or system, superglue automatically grants it to the creator's personal role:

* New tool -> appended to the creator's personal tool allowlist
* New system -> appended to the creator's personal system allowlist

This keeps users on restricted allowlists able to use the resources they create without adding those resources to a shared base or custom role.

## Managing Roles

### Via The Dashboard

1. Navigate to **Control Panel -> Organization**
2. Open **Access Rules**
3. Use **Org Roles** to create and edit shared roles
4. Use **Personal Roles** to grant per-user tool and system access

### Via The API

Roles are represented with binary allowlists:

```json theme={null}
{
  "tools": "ALL",
  "systems": ["salesforce", "hubspot"]
}
```

Only `"ALL"` means open access. Empty arrays, missing fields, or `null` mean no direct access from that role.