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

# Permissions

> Two layers control who can see and change what—company roles set the baseline, and resource permissions grant access to specific items. Access then flows down through the resource graph.

The platform separates **who you are in the company** from **what you can touch**. Company roles set the floor; resource permissions raise it for specific items; and access **cascades** from a resource to everything derived from it.

## Company roles

Every member of a company has exactly one role:

| Role       | What it grants                                                                                                                                           |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Full access to everything in the company. Bypasses all permission checks and row-level security.                                                         |
| **Admin**  | Same operational surface as Owner—build pipelines, design apps, edit ontology, manage members. Subject to resource permissions and RLS where they apply. |
| **Viewer** | Read-only by default. Can use apps, dashboards, and queries. Cannot edit pipelines, ontology, or settings.                                               |

Roles are assigned from **Settings → Team**. Only Owner and Admin can change them.

## Resource permissions

On top of the company role, individual resources carry their own access list. Almost everything you can name is a permissionable resource:

| Resource               | What permissions gate                                                         |
| ---------------------- | ----------------------------------------------------------------------------- |
| **Folder**             | A container for projects and dashboards. Sharing it shares everything inside. |
| **Project**            | The pipelines, runs, dashboards, and databases the project produces.          |
| **Dashboard**          | A dashboard and the data it reads.                                            |
| **Database**           | The rows in a project database (dataset).                                     |
| **Entity**             | An ontology entity's rows, subject to row-level security.                     |
| **Application**        | An app and the entities it is bound to.                                       |
| **Workflow**           | A trigger-driven workflow and who can run it.                                 |
| **File / File folder** | Uploaded files and the datasets parsed from them.                             |
| **Integration**        | A connected provider, its credentials, and the datasets it syncs.             |

Each grant has a **level**:

| Level      | Can do                                                                                                   |
| ---------- | -------------------------------------------------------------------------------------------------------- |
| **Viewer** | Read the resource.                                                                                       |
| **Editor** | Read + modify. For projects, edit pipelines; for databases, write rows; for integrations, change config. |
| **Admin**  | Editor + manage permissions on this resource.                                                            |

Levels are strictly ordered: `viewer < editor < admin`.

A grant can be given to an individual member **or to a [group](/docs/permissions/groups)**. A group grant reaches every member of the group.

## How the layers combine

The platform computes your **effective level** on any resource by taking the **highest** access any of these paths gives you:

1. **Owner** short-circuits every check—no resource grants needed.
2. A **direct grant** to you on the resource.
3. A grant to any **group** you belong to.
4. An **inherited grant** from a parent or container—see [Permission inheritance](/docs/permissions/inheritance).

If none of those apply, you have no access. Access is **additive**: there is no "deny" grant. To take access away, remove the grant (or the group membership, or the parent grant) that provides it.

## Auto-grants on create

Whoever creates a project or a database gets an **Admin** grant on it automatically. They keep that grant until someone with Admin on the resource (or an Owner) revokes it.

## Manage permissions

From the resource's settings panel (the shield icon on a project, database, entity, app, file collection, or integration), use the **Access** panel to:

* Add a member or group at a chosen level.
* Change an existing grant.
* Revoke a grant.

The panel has two sections. **Members** lists direct grants you can edit. **Also has access** lists everyone who reaches the resource indirectly—through a parent, a group, or a data link—and shows where each came from. See [Permission inheritance](/docs/permissions/inheritance).

Only Owners and members with **Admin** on the resource can manage its permissions.

## Next

* [Permission inheritance](/docs/permissions/inheritance) — how a grant cascades to everything derived from a resource.
* [Groups](/docs/permissions/groups) — grant access to many members at once.
* [Attributes](/docs/permissions/attributes) — describe members, then drive groups and policies from those values.
* [Row-level security](/docs/permissions/row-level-security) — control which rows inside a database or entity a member can see.