> ## 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.

# Permission inheritance

> Access flows down the resource graph. Sharing a container shares everything inside it, and data a resource merely reads becomes view-only for the people who can see it.

Resources aren't islands. A folder contains projects, a project produces databases, an app reads entities, an integration syncs datasets. The platform models all of this as a **graph**, and a grant on one resource **cascades** to everything derived from it.

You never have to grant the same thing twice. Share the folder, and the projects, dashboards, and datasets inside it come along.

## Two kinds of edges

Every link in the graph is one of two kinds, and they propagate access differently.

| Edge            | Example                                                                                                   | What the level does                                                                   |
| --------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| **Containment** | Folder → project, project → dashboard, file folder → file                                                 | Level passes through **unchanged**. Editor on the folder means Editor on the project. |
| **Data link**   | Dashboard → the data it queries, app → the entities it's bound to, database → the entity promoted from it | Level is **capped at Viewer**, and stays capped further downstream.                   |

The data-link cap is the important rule: **seeing something that reads a dataset never lets you edit that dataset.** A dashboard reads `factures`; sharing the dashboard lets a viewer see those rows (filtered by row-level security) but never edit the underlying data.

## The full cascade map

When you share a resource, here is exactly what comes with it. This is the copy you'll see in the **Access** panel under each resource:

| Share this             | …and you also share                                                      |
| ---------------------- | ------------------------------------------------------------------------ |
| **Folder**             | Every project and dashboard inside it; data they read becomes view-only. |
| **File folder**        | The files inside it and their datasets.                                  |
| **Project**            | Its dashboards and produced datasets; data it reads becomes view-only.   |
| **Dashboard**          | The data it queries (rows can still be filtered by row-level security).  |
| **Database (dataset)** | The entities promoted from it (view-only).                               |
| **Entity**             | Its rows, subject to row-level security.                                 |
| **Integration**        | The datasets it syncs.                                                   |
| **File**               | The datasets parsed from it.                                             |
| **Application**        | The entities it is bound to (view-only).                                 |

The headline example: **granting access to an app gives access to the entities it reads.** A viewer who can open an app can read every entity in the app's [bindings](/docs/applications/bindings)—at Viewer level, because the app→entity link is a data link. They can still write through the app's [actions](/docs/applications/actions) if a binding allows it, but they can't edit those entities directly.

## How effective access is computed

Your level on any resource is the **highest** level across every path that reaches it:

* A **direct grant** to you.
* A grant to any **group** you belong to.
* An **inherited grant** from a container or a resource upstream, with the data-link cap applied to any path that crosses a data link.

Access is **additive**—the platform takes the maximum, never a minimum. If a folder grant gives you Viewer on a database and a direct grant gives you Editor, you have Editor. There is no way to subtract access on a child while keeping it on the parent; revoke the grant that provides it instead.

Inheritance is **computed live**. Move a project into a different folder, change which entities an app is bound to, or repoint a dashboard's query, and effective access updates immediately—nothing to re-share.

## Seeing where access comes from

Open the **Access** panel on any resource (the shield icon). It has two sections:

* **Members** — direct grants on this resource. These are the ones you add and edit here.
* **Also has access (N)** — everyone who reaches the resource indirectly. Each person shows a chip for **where** their access comes from: `via Finance (folder)`, plus the group name if it arrived through a group. A path that crossed a data link is marked **capped at viewer**.

Admins can use this to answer "why can this person see this?" without tracing the graph by hand.

## Owner bypass

Company **Owners** see and edit everything regardless of grants or inheritance. Admins and viewers are subject to the rules above.

## Next

* [Groups](/docs/permissions/groups) — one grant, many members.
* [Row-level security](/docs/permissions/row-level-security) — narrow which rows inside a shared dataset a member sees.