# Managing access (/access/managing-access)
Grant and revoke feature permissions from the portal's Access control screens, to a person or through a role.
The administrator's guide to the portal's **Access control** screens: granting to a person, granting
the same set through a role, reading the permission grid, and knowing when a change did nothing.
You need **Administer platform** (`can_admin`); without it, **Access control**
is not in your sidebar and opening it directly shows "Not authorized". These
screens grant feature permissions only — data grants are made in the [Data
Catalog](/catalog/data-permissions).
## Find the screens
**Access control** sits in the **Administration** group and opens on **Permissions**, with two tabs:
- **Permissions** — one row per person: roles, permissions, and account status (**Active**,
**Invited** or **Inactive**). Answers "what can this person do?"
- **Roles** — one row per role: what it grants, how many people are in it, and a delete button.
Answers "what does this bundle mean?"
The same group holds **Identity**, the single sign-on directory where accounts live. The whole group
appears only for **Administer platform**.
## Read the permission grid
Both tabs use the same grid. The five permission columns are abbreviated — **View**, **Run**,
**Dash**, **Nbk**, **Adm** — with the full name in each column's tooltip. Each cell is one of four
states, keyed above the table:
| Cell | Meaning | Clickable |
| -------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Filled square — **Direct grant** | Granted to this person or role right here. | Yes. Clicking removes it. |
| Outlined square with a cross — **Granted by role** | Comes from a role this person is in. | No. Remove them from the role, or take the permission off the role. |
| Hatched square — **Cascaded grant** | Implied by a higher permission: Run implies View, Administer platform implies all. | No. Remove the higher permission instead. |
| Dashed outline — **No access** | Not held. | Yes. Clicking grants it. |
Two states are not clickable — the grant you see is not the one doing the work; hover for the
tooltip that names it. **Granted by role** never appears on the Roles tab, since a role cannot be in
a role.
## Grant a permission to one person
### Open Permissions
Select **Access control**. Everyone in the directory is listed — including people who hold nothing
and inactive accounts, since those are states you act on. Use **Filter people…** to narrow by name,
email, or role.
### Click the cell
Click the cell where the person's row meets the permission's column. It is written immediately —
there is no save button, and the table reloads so cascades show as the server resolved them.
### Tell them to reload
Feature permissions are checked live, so no sign-out: their next page load picks it up, within about
fifteen seconds. Notebooks is the exception — it checks at sign-in, so a new grant applies at their
next Notebooks sign-in and a revoke leaves a running server alone. See
[when a change takes effect](/access/how-access-works#when-a-change-takes-effect).
Removing a permission is the same click on a **Direct grant** cell.
## Grant the same set to several people
Use a role when several people need the same bundle. These are starting points, not enforced — and
each still needs a separate [data grant](/catalog/data-permissions) before the person can read
anything.
| Role for | Tick | Because |
| ----------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Analysts who query data | **Dash**, and **Nbk** if they work in notebooks | SQL Lab comes with Dashboards; what they can query is a data grant, not this. |
| Engineers who build pipelines | **Run**, plus **Nbk** | Run implies View, so do not tick both. Editing connections, variables, pools, config and backfills needs **Adm**. |
| Dashboard builders | **Dash** | Everyone who gets in sees the same charts; a chart on data they cannot read will error for them. |
| Administrators | **Adm** | Implies the other four. Grant no others — they would be redundant and harder to revoke. |
### Create the role
On the **Roles** tab, type a name into **New role name…** and select **Create role**. The name is
the identifier: lowercased, spaces become underscores, and it must be lowercase letters, digits, `-`
and `_`, starting with a letter or digit. A role with no permissions yet is labelled _grants nothing
yet_.
### Give the role its permissions
Click the cells in the role's row, the same way as for a person.
### Put people in it
Membership is edited on the **Permissions** tab, not here. In a person's **Roles** cell, open the
dropdown and tick the role. The menu stays open so you can set several roles in one visit; each tick
is written immediately.
The Roles tab shows how many people are in the role; hover the count for their email addresses.
**Deleting a role** takes two clicks — the delete button, then **Confirm**. Everyone in it loses what
it granted, and the role's own grants go with it, so recreating the same name later restores nothing.
## What these screens do not do
- Not data grants — that is the Data Catalog's **Permissions** tab, on a warehouse, namespace or
table. See [data permissions](/catalog/data-permissions).
- Not pipeline scope — pipeline permissions are fleet-wide; no grant here changes which pipelines
someone sees.
- Not accounts — people are added, invited and deactivated in **Identity**. Deactivating someone
there stops them signing in but keeps their grants here, so reactivating them restores their
access as it was.
- Not groups — there are no groups here; use roles to give several people the same permissions.
What each permission unlocks, and where it is enforced.
The two layers, and when each change takes effect.