Lineage Permissions¶

Lineage is governed by user roles, the platform-level roles that apply across the deployment. Team permissions do not filter the graph: they apply to editing connections, to reading the job details an OpenLineage producer sent, when you leave the graph 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.

User Roles¶

UI Behavior Without Permission¶

Team Permissions¶

The container graph is not filtered by team, so a Member can see connections to containers in datastores their teams do not cover. Seeing a connection does not grant permission to edit it.

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 requires Editor permission on every datastore associated with the connection, for both Members and Managers. A cross-datastore connection requires Editor on both ends. Fields inherit the requirement from their container's datastore. Admins can edit lineage in any datastore. An Admin restricted to a team follows that team's permissions.

Sending OpenLineage events follows the same rule: an event changes a connection only when the caller has Editor on the datastore of every container it touches, on both sides of a cross-datastore connection. That covers the connections an event retires as well as those it creates, whether a COMPLETE run or job definition no longer lists them or a DROP or RENAME retires them.

OpenLineage events resolve each dataset to the matching datastores the caller can edit. If two datastores point to the same host, database, and schema, a caller with Editor on one and Viewer on the other changes only the Editor datastore. Metadata, retirement by an authoritative event, and DROP or RENAME follow the same scope. Existing connections involving a datastore outside that scope stay unchanged.

A table that has not been catalogued yet still requires Editor when its identifier matches a known datastore. If none of the matching datastores grants Editor, the event is denied rather than treating the table as an outside asset. A denied event applies no changes. Sent on its own it returns 403 Forbidden. In a list, the request answers 201 Created with the denial in that event's status, and the other authorized events still apply.

The UI offers editing based on the datastores of a connection's ends, and Add upstream or Add downstream lists only the datastores where you have Editor. An end outside Qualytics adds no requirement in the UI, but when an OpenLineage connection's outside end names a dataset that matches a catalogued datastore, the API still requires Editor there and the delete control shows why it was refused.

Seeing a connection from OpenLineage does not show everything its producer sent. The record of who asserted it keeps its attribution for anyone who can see the connection: the producer, the kind of event, and when. The job's identity, run, datasets, transformations, submitter, and SQL or source code can quote values from your data, so they are shown only to users with the Viewer team permission on the datastore of every container the connection touches. Unrestricted Admins always see them.

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.
• An OpenLineage connection is retired rather than removed, so who asserted it stays on record. It comes back when a job asserts it 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.

See Also¶