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

# Roles

> Group permissions into custom roles or use oleander’s system-managed roles.

A role is a named collection of permissions. It can combine compute, warehouse, and administration permissions. A principal can hold multiple roles, and a role can be assigned to multiple principals. API keys use their owner's roles and cannot receive assignments directly.

Manage roles in [Settings → Organization → Roles](https://oleander.dev/app/settings/roles).

## Custom roles

1. Choose **Create role**, enter a name and optional description, and add permissions.
2. For each permission, choose **Resource type**, **Scope**, and **Actions**, then **Apply permissions**.
3. Create the role and use its **Assign users** action to assign principals. Use **Permissions** to review or change its grants.

Creating an empty role requires **Create** for **Roles → All roles**. Adding new permission definitions also requires **Create** for **Permissions → All permissions**. Attaching permissions and assigning principals require the additional [delegation grants](/iam/permissions#delegating-access).

Changing a role's permissions affects every principal assigned that role. Removing an assignment removes that role's contribution to the principal's access; other assigned roles may still grant the same access.

## System-managed roles

Oleander provisions the following roles for each organization and controls their definitions. You cannot delete them or change their permission composition. Authorized administrators can assign and unassign them. Their system-managed permission definitions cannot be edited or deleted.

| Role                | Grants                                                                                                                                                                                                                                                |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `OrganizationAdmin` | Includes all grants from the other system-managed roles, plus Describe, Select, Create, Modify, Manage grants, and Pass grants across the entire warehouse.                                                                                           |
| `UserAdmin`         | Manages principals, roles, and permission definitions; manages Application and Agent API keys; delegates access across all resource categories. Includes principal Modify, Enable, and Disable definitions, whose operations are not implemented yet. |
| `SecurityAdmin`     | Manages catalog registrations, connections, roles, and permission definitions. Delegates catalog and connection access. Does not itself grant principal administration, compute execution, or warehouse data access.                                  |
| `JobOperator`       | Execute and Abort on all compute engines. No warehouse data grants.                                                                                                                                                                                   |
| `TokenSelfAdmin`    | Describe, Create, and Revoke for API keys owned by Self—the principal using the role.                                                                                                                                                                 |
| `Public`            | Contains no permissions. Grants no compute or data access by itself.                                                                                                                                                                                  |

`UserAdmin` grants authority to delegate compute and warehouse access, without directly granting execution or data-reading actions. `SecurityAdmin` can manage role definitions, but assigning those roles still requires authority over the target principal.

`OrganizationAdmin` remains subject to resource safeguards: it cannot delete system-managed definitions, delete the built-in `oleander` catalog, or manage another Human's personal API keys.

## Removing roles

A custom role cannot be deleted while referenced by principal assignments or invitations. Deleting an eligible role removes its permission associations, not the shared permission definitions or principals.

Unassigning the last remaining **OrganizationAdmin** is blocked. This protection applies to role unassignment; membership removal and leaving an organization do not provide the same complete last-admin protection.

See [Resources and actions](/iam/resources-and-actions#roles) for role-management permissions.