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.
Prerequisite
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.
Find the screens
Access control sits in the Administration group and opens on Permissions, with two tabs:
- Permissions — one row per person: roles, permissions, account status. 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.
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 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 and pools 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.
- Not pipeline scope — pipeline permissions are fleet-wide; no grant here changes which pipelines someone sees.