> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md).

# Roles and permissions

The built-in Admin, Manager, and Viewer roles, what each can do, and how to design custom roles in e6data.

A **role** is a named set of permissions. Users, groups, and service accounts are assigned one or more roles; the union of those permissions defines what they can do. For the underlying permission grammar, see [Control Plane vs Compute Plane permissions](/query-engine/guides/security/identity-and-rbac/control-plane-vs-compute-plane-permissions.md).

## Built-in roles

Every workspace ships with three built-in roles. Most organizations don't need anything else.

| Role        | Typical user                      | What they can do                                                                                                             |
| ----------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Admin**   | Organization owner, platform team | Full access to all workspace operations, including settings, access control, and version upgrades.                           |
| **Manager** | Data engineers, BI leads          | Create and edit clusters and catalogs, run queries, and view the whole workspace - but not manage users, roles, or settings. |
| **Viewer**  | Analysts, dashboard consumers     | Run queries on assigned clusters and catalogs; no edit access.                                                               |

### What each built-in role can do

| Capability                                                 | Admin | Manager | Viewer |
| ---------------------------------------------------------- | :---: | :-----: | :----: |
| **Workspace**                                              |       |         |        |
| View workspace                                             |   ✅   |    ✅    |    ✅   |
| Edit workspace settings                                    |   ✅   |    -    |    -   |
| Suspend / resume workspace                                 |   ✅   |    ✅    |    -   |
| Delete workspace                                           |   ✅   |    -    |    -   |
| **Catalogs**                                               |       |         |        |
| View catalogs                                              |   ✅   |    ✅    |    ✅   |
| Create / edit / refresh / delete catalog                   |   ✅   |    ✅    |    -   |
| **Clusters**                                               |       |         |        |
| View clusters                                              |   ✅   |    ✅    |    ✅   |
| Create / edit / suspend / delete cluster                   |   ✅   |    ✅    |    -   |
| **Queries**                                                |       |         |        |
| Run queries, view own history                              |   ✅   |    ✅    |    ✅   |
| View all query history, cancel any query                   |   ✅   |    ✅    |    -   |
| **Access control**                                         |       |         |        |
| View users and roles                                       |   ✅   |    ✅    |    -   |
| Invite/remove users, manage roles, manage service accounts |   ✅   |    -    |    -   |
| **Settings**                                               |       |         |        |
| Configure SSO, trigger version upgrades                    |   ✅   |    -    |    -   |
| Configure observability                                    |   ✅   |    ✅    |    -   |

The complete, exhaustive permission list lives in the [Permissions matrix](/query-engine/reference/platform-reference/permissions-matrix.md) reference.

## Assigning roles

From the Console (Control Plane for org scope, or a workspace for compute scope):

1. Open **Access Control → Users** (or **Service Accounts**, or **Groups**).
2. Select the identity.
3. Click **Add role**.
4. Pick a role and a scope - workspace-wide, or limited to specific catalogs or clusters.
5. Save.

A user can hold different roles in different workspaces - for example, Admin in `dev` and Viewer in `prod`. Assigning roles to a [group](/query-engine/guides/security/identity-and-rbac/users-groups-service-accounts.md) and managing membership is usually cleaner than per-user assignment.

## Group-to-role mapping via SSO

If you use [SSO](/query-engine/guides/security/authentication/sso-setup.md), you can map IdP groups to e6data roles so users get the right role automatically on sign-in - no per-user assignment.

## See also

* [Control Plane vs Compute Plane permissions](/query-engine/guides/security/identity-and-rbac/control-plane-vs-compute-plane-permissions.md)
* [Permissions matrix](/query-engine/reference/platform-reference/permissions-matrix.md)
* [Users, groups, and service accounts](/query-engine/guides/security/identity-and-rbac/users-groups-service-accounts.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.e6data.com/query-engine/guides/security/identity-and-rbac/roles-and-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.