Lineage Permissions

Lineage is governed by user roles, the platform-level roles that apply across the deployment, and by the Lineage add-on being enabled. Team permissions do not filter the graph: they apply when you leave it to open a container, to a datastore's own lineage and impact analysis, and to the operations that produce lineage. The details are under Team Permissions below.

The Lineage Add-on

Lineage is an add-on on top of the base platform. With the add-on disabled, the Lineage tab is hidden on containers and on datastores, and the API refuses lineage requests. A saved link to either tab opens the container's or the datastore's Overview instead.

An Admin reviews and toggles add-ons from the Add-ons side panel in the top-right menu.

User Roles

Action	Member	Manager	Admin
Open a container's Lineage tab and read the graph
Expand the graph and focus on a field
Open a datastore's Lineage tab, its map and its read-only canvases
Run an impact analysis and export it
Open a connection and see where it came from
Copy the name of a node
Add an upstream or downstream connection
Add a field-level connection
Edit a connection (API only)
Delete a connection

UI Behavior Without Permission

Scenario	What the User Sees
A user without the Manager role opens a node's menu	The menu still opens and Copy Name works, since copying needs no write access. Add upstream and Add downstream are not listed.
A user without the Manager role hovers a connection	The connection's badge shows where it came from, and no delete control appears beside it.
The Lineage add-on is disabled	The Lineage tab is not shown on any container or datastore, for every role.
A user whose team permission on a datastore is Reporter opens its Lineage tab	The tab is shown, and the map does not load. A datastore's lineage needs the Viewer team permission on that datastore.
A user with the Manager role opens a datastore's Lineage tab	The map, the lineage between two datastores and the all-containers canvas show no + buttons and no delete control. Editing is offered once a single container's lineage is open.
A node belongs to a datastore the user's teams do not cover	The node renders with its name, datastore, counts and badge like any other. On a container's Lineage tab, clicking Open this table's lineage opens a page that refuses the user, since it requires the Reporter team permission on that datastore.

Team Permissions

The graph is not filtered by team. Every lineage request is checked for the user role above and for the add-on, and for nothing else, so a Member sees every connection of the container they opened, including connections to containers in datastores their teams do not cover.

For such a container the node is drawn in full: its name, the datastore it lives in, its field counts, and its anomaly badge. What team permission governs is the step out of the graph. On a container's Lineage tab, Open this table's lineage on the node opens that container's own Lineage tab, which is part of the container's page and requires at least the Reporter team permission on its datastore. The same applies to the arrow beside another datastore's name on a datastore map card, and to View table in an impact analysis. A user without the team permission is refused there, while the node itself stays visible on the canvas. An Admin is never refused, since the Admin role carries access to every datastore.

Adding, editing, and deleting connections follow the Manager role alone. A Manager can connect two containers, or delete the connection between them, whatever team permission they hold on either datastore.

The graph differs from the container listing, which shows only the datastores a user's teams cover, so a container that never appears in a listing can still appear as a node in a graph.

A datastore's own lineage is the exception. Its map, the lineage between two datastores, the all-containers canvas and the ranking in impact analysis read out the whole datastore, so they need at least the Viewer team permission on that datastore. A user whose team permission there is Reporter can open the datastore's page, but its Lineage tab is refused. The impact analysis of a single container lists everything that container reaches, so it needs the Viewer team permission on the datastore the container belongs to. Its Export is hidden in deployments where downloads are turned off.

Deleting Is Not Limited to Manual Connections

A connection can be deleted whatever created it, and the delete control does not depend on its category. What differs is whether it stays deleted:

A manual connection stays gone, because nothing else produces it.
A data catalog connection comes back on the next sync of that data catalog, since the data catalog is the source of truth for it.
A collected connection comes back the next time a collection observes the relationship again.
A Qualytics managed connection comes back when the computed container is saved again, or when the operation writes the table again.

Deleting is the right move for a relationship that is genuinely wrong. For one that is merely no longer wanted, remove it where it is produced: in the data catalog, or in the pipeline the source records.

Lineage Qualytics Produces

The connections Qualytics generates itself carry no separate permission. They follow the operation that produces them: whoever can save a computed container, or run a materialize or a scan, produces the lineage that comes with it. Collect lineage on a Sync is available to whoever can run that Sync.

This is why a Member who cannot add a connection by hand can still cause connections to appear, by running an operation that writes one.