The Dependant tab in a Lake table's popup shows what uses the table: the objects that read it, the Minds and presentations built on it, and the links and grants that touch it. Check it before you change or remove a table, so you know what your change can affect.
The tab groups what it finds by kind: Warehouse tables and transformations, Lake tables, write-back objects, Minds, references, presentations, DataPrism semantic models and API data access grants. Each group carries a count badge, for example 1 Mind.
Some dependants sit outside your access. They still use the table, so your change or removal can break them even though you cannot open them. Ask their owners before you continue.
How each row opens, how rows you cannot access appear, and how the list reports a failed check are on Check a table's dependants.
The check counts the readers DataMind records: dependencies between objects, and Minds with the table linked. A reference between two tables is shown in the list so you can open the linked table, but a reference on its own is not counted as a read.
Uses can also point at single columns: a data access grant reads the columns listed on its row, a reference links one column of each table, and a Mind can be granted only some of a table's columns.
Fact and Dimension rows are the only ones that carry a source-system line. It names the source systems the object involves, or reads ALL when the object is not limited to particular ones.
You can remove a table from its Settings tab (see Run, stop and troubleshoot loads), from the Lake tree (see Delete Lake items), or in bulk from Batch edit and organise. Whichever way you start, the same check runs first:
Objects that use the table are not removed with it. They keep pointing at a table that is gone until you fix or remove them. Ask the owners of dependants you cannot see before you confirm.
The dialog tells you when the list is not the whole story. If part of the check fails, it warns Could not load every dependant, so the list may be incomplete., and objects outside your access are counted, not named (2 are not visible to you.). Both mean dependants may be missing from the list. For what each warning means, see Deleting a table with dependants and Lake troubleshooting.
Removing a table needs Remove Lake Objects; see Who can do what in the Lake.
Some uses do not just warn; they refuse the removal until you clear them:
The same protection covers single columns. A column that Minds use cannot be removed, and a column read by a data access grant is refused until the grant is revoked.
It is shown in the list, so you can open the linked table, but a reference on its own is not counted as a read. The check counts the readers DataMind records: dependencies between objects, and Minds with the table linked.
Warehouse tables and transformations, Lake tables, write-back objects, Minds, references, presentations, DataPrism semantic models and API data access grants.
Fact and Dimension rows are the only ones with a source-system line. It lists the source systems the object involves, or reads ALL when the object is not limited to particular ones.
Yes. The confirmation checks first; when something depends, the button reads Delete anyway. The check itself only warns: it does not change what gets removed. Read the list before you confirm, because the objects stay behind and may break, and some uses refuse the removal completely (the section above lists them). Deleting a table with dependants covers the dialog in full.
A live data access grant, a permission group or a table that Minds use, a write-back table that uses it as its source, and tables that depend on it. Each refusal names its cause and what to clear first; the section above lists the messages.
A column that Minds use cannot be removed, and a column read by a data access grant is refused until the grant is revoked. Remove the column from those Minds first, or revoke the grant.