# Permissions reference (/access/permissions-reference)

The five Databaas permissions, what each one unlocks, what it implies, and where each is enforced.

The five permissions below are the whole feature-permission model: deployment-wide, with no per-pipeline
or per-dashboard variant, and none of them grants access to data.

## The five permissions

| Permission | Capability | Area | What it unlocks | Implies |
| ---------- | ---------- | ---- | --------------- | ------- |
| View pipelines | `can_view_pipelines` | Pipelines | See every pipeline, its runs, logs and code. | — |
| Run pipelines | `can_run_pipelines` | Pipelines | Trigger, clear, mark and pause every pipeline. | View pipelines |
| Use dashboards | `can_use_dashboards` | Dashboards | Open Superset, SQL Lab included. | — |
| Use notebooks | `can_use_notebooks` | Notebooks | Open Jupyter. | — |
| Administer platform | `can_admin` | Administration | The whole **Administration** group in the sidebar — **Access control** and **Identity** — plus Airflow's connections, variables, pools, config and backfills, and deleting pipelines. | All four of the above |

You hold a permission by direct grant, through a role you are in, or because a permission you hold
implies it. Features check the capability in the second column, not the name — so an implied permission
works exactly like a granted one.

### The cascades

- **Run pipelines implies View pipelines.** An operator does not need both.
- **Administer platform implies everything.** An administrator does not need any other permission.

There is no deny: a grant only ever adds, so granting something a person already gets another way
changes nothing. Taking access away means removing the grant that actually confers it.

## Where each permission is enforced

Every feature checks for itself, on the same shared answer. Hiding a feature from the portal navigation is
not the boundary.

| Where | What is checked | When | Notes |
| ----- | --------------- | ---- | ----- |
| Portal navigation and Overview | All five | Every page load | Features you cannot open are not listed. The **Administration** group appears only for Administer platform. |
| Portal **Access control** screens | Administer platform | Every request | Otherwise the screen says "Not authorized". |
| Portal **Identity** link | Administer platform | Every page load | Listing only; Identity then applies its own administrator rules. |
| Portal **Data Catalog** | Nothing | — | Deliberately ungated: its contents are already per user. |
| Pipelines — reading a pipeline, its runs, logs and code | View pipelines | Every request | Fleet-wide. |
| Pipelines — trigger, clear, mark, pause | Run pipelines | Every request | |
| Pipelines — deleting a pipeline | Administer platform | Every request | Deleting removes its history irrecoverably. |
| Pipelines — Connections, Variables, Pools, Config, Backfills | Administer platform | Every request | |
| Dashboards (Superset) | Use dashboards | Every access check | A door, not a filter — see below. |
| Notebooks (JupyterHub) | Use notebooks | At sign-in only | Login is the only boundary it offers. |
| Data, in any engine | None of these | Every query | Decided by the catalog, as the signed-in user. |

**Notebooks are checked at sign-in.** A grant applies the next time you sign in to Notebooks; a
revoke does not stop a notebook server already running.

**Superset is a door, not a filter.** Everyone who can open it holds the same role there and sees
the same datasets, charts and dashboards. What differs between two people is which queries return
rows — decided by data permissions, not by anything on this page.

## What these permissions do not control

- **Which pipelines you see.** Fleet-wide: if you can open Pipelines, you see every pipeline in the
  deployment, its runs, code and task logs — including logs from pipelines touching data you have no
  grant on.
- **Which dashboards, charts or datasets you see.** Everyone who gets into Superset sees the same list.
- **Which data you can read.** Granted per warehouse, namespace and table in the Data Catalog and
  enforced on every query. See [data permissions](/catalog/data-permissions).

## Roles

A role is a named bundle of these five permissions with people assigned to it — the only grouping
construct in this model, and it groups people **for feature permissions only**. Being in a role called
`analyst` grants nothing in the catalog.

- A role's permissions are edited on the **Roles** tab; its membership per person on the
  **Permissions** tab.
- A role cannot contain another role.
- The name is the identifier: lowercase letters, digits, `-` and `_`, starting with a letter or digit.
- Deleting a role removes its grants too, so recreating one with the same name does not restore access.

See [managing access](/access/managing-access) for the screens.

<Cards>
  <Card title="How access works" href="/access/how-access-works">
    The two layers, and when each change takes effect.
  </Card>
  <Card title="Managing access" href="/access/managing-access">
    Granting and revoking, screen by screen.
  </Card>
</Cards>