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 gate the Lineage tab itself, and the operations that produce lineage still respect the datastore access of the context they run in.
The Lineage Add-on
Lineage is an add-on on top of the base platform, and the entitlement is checked on every lineage request rather than only when the tab renders. With the add-on disabled, the Lineage tab is hidden and the lineage endpoints refuse the call, so a saved link or a script reaches nothing either.
An Admin reviews and toggles add-ons from the Add-ons side panel in the top-right menu.
User Roles
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, for every role. |
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.
See Also
-
How It Works
The connection model, the two levels of granularity, the rules a connection has to obey, and how to find the containers that have one.
-
Lineage Sources
The four categories a connection can come from, and how each is created, updated, and removed.
-
Reading the Graph
Direction, nodes, assets outside Qualytics, where a connection came from, and expanding the graph.
-
Field-level Lineage
Expanding field lists, field metadata, and the focal field workflow.
-
Examples
Enrolling a warehouse, a medallion pipeline across datastores, a remediation table, and a hop only a person can record.
-
Best Practices
Which source to lean on, how to run collection, and how to keep a graph you can trust.