> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/features/data-discovery/entity-detail-page.md). # Data entity detail page Clicking a data entity in [Search](/features/data-discovery/search.md), in the [Directory](/features/data-discovery/directory.md), in a [Catalog Overview](/features/data-discovery/catalog-overview.md) tile, in a lineage node, or in the [Activity feed](/features/active-platform-features/activity-feed.md) lands the user on the same per-entity detail page. The **Overview tab** is the default landing surface — a single composed page showing everything the catalog knows about the entity, with edit affordances gated by per-panel permissions and per-class composition rules. This page is the canonical reference for the detail-page composition itself. For the aspect-level deep dives — authoring the [Markdown description](/features/data-discovery/entity-description.md), curating [custom metadata](/features/data-discovery/custom-metadata.md), annotating [individual columns](/features/data-discovery/per-column-annotation.md) on a dataset's Structure tab, applying [tags](/features/data-discovery/tagging.md), curating [business names](/features/data-discovery/business-names.md), wiring [statuses](/features/data-discovery/statuses.md), attaching [files](/features/data-discovery/attachments.md), reading the [stale indicator](/features/data-discovery/metadata-stale.md), and grouping into [Data Entity Groups](/features/data-discovery/groups-domains.md) — follow the per-aspect pages cross-linked below. ## Overview tab composition The Overview tab renders a two-column grid for every catalogued entity: * **Main column (left)** — class-driven stats, Description, Attachments, Metadata, optional Expectations, optional Metrics. * **Sidebar (right)** — General identity + Owners, optional Data Quality panels, Groups, Tags, Terms. Twelve sub-panels combine on the surface: | Panel | Column | What it shows | Aspect page | | ------------------ | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Class-driven stats | Main | A class-specific summary block — dataset structure card, transformer source/target list, consumer input list, quality-test datasets, data-input output list, relationship endpoints, or entity-group member set, depending on the entity's class. | [Main Concepts → Data Entity Class](/introduction/main-concepts.md) | | Description | Main | The entity's human-readable Markdown description, with linked terms inline. | [Entity description](/features/data-discovery/entity-description.md); [Business Glossary](/features/data-glossary/business-glossary.md) for the inline term-link surface. | | Attachments | Main | Files and remote-URL attachments uploaded for the entity. | [Data Entity Attachments](/features/data-discovery/attachments.md) | | Metadata | Main | Custom (operator-curated) and predefined (collector-ingested) metadata fields in one combined list. | [Custom metadata](/features/data-discovery/custom-metadata.md) | | Expectations | Main (conditional) | Renders only when the entity has quality-test expectations — parameters and linked URLs from the test definition. | [Test Results Import](/features/data-quality/test-results-import.md) | | Metrics | Main (conditional) | Renders only for datasets — column-level stats and metrics. | — | | General | Sidebar | Namespace, datasource link, source-side timestamps, view count (see the [view count caveats](#general-panel-view-count-caveats) below), ODDRN, and the Owners list. | [Authorization → Owners](/configuration-and-deployment/enable-security/authorization/owners.md) | | DQ SLA report | Sidebar (conditional) | Renders only for datasets with at least one quality-test report; shows the SLA roll-up. | [Quality Dashboard](/features/data-quality/dashboard.md) | | DQ test report | Sidebar (conditional) | Renders alongside the SLA report; shows the latest passed / failed / aborted totals. | [Quality Dashboard](/features/data-quality/dashboard.md) | | Groups | Sidebar | Data entity groups this entity belongs to. | [Data Entity Groups & Domains](/features/data-discovery/groups-domains.md) | | Tags | Sidebar | Tags applied to the entity. | [Manual Object Tagging](/features/data-discovery/tagging.md) | | Terms | Sidebar | Linked business-glossary terms. | [Business Glossary](/features/data-glossary/business-glossary.md) | The page header above the tabs shows the entity name, the class badges, the type badge, the [stale indicator](/features/data-discovery/metadata-stale.md), the [status](/features/data-discovery/statuses.md), and (where applicable) the "Edit business name" / "Edit group" / "Share" buttons. Header affordances follow the same per-class and per-permission rules as the Overview composition; see [Class and type badges](#class-and-type-badges) below. Below the Overview tab, additional class-driven tabs appear — **Structure** (datasets only; see [Per-column annotation](/features/data-discovery/per-column-annotation.md) for the column-level composer that lives on this tab), **Lineage** (most classes; see [Data Lineage](/features/data-lineage.md)), **Test reports** and **History** (quality tests, transformer runs), **Linked entities** (per-class linkage), **Discussions** (when [Data Collaboration](/features/active-platform-features/data-collaboration.md) is enabled), and **Activity** (the [per-entity Activity feed](/features/active-platform-features/activity-feed.md) audit trail). Which tabs appear depends on the entity's class set; the next section names the mapping. ### General panel — view count caveats The General panel's **view count** is the running total of times this entity's detail page has been fetched. One version note and one caveat are worth knowing before you read or rely on the number. {% hint style="info" %} **One page-open registers one view as of 0.28.0 — releases up to 0.27.x counted +2.** In earlier releases each page-open fetched the entity detail twice (a front-end double-fetch), so a single visit added **2** to the number. From 0.28.0 a visit adds exactly 1. Counts accumulated on earlier releases overstate real visits by roughly a factor of two, and the counter is not rebased on upgrade — treat pre-0.28.0 numbers as a relative popularity hint, not an exact visit tally. {% endhint %} {% hint style="warning" %} **View count is the sole signal behind the home-page Popular ranking, and it is trivially inflatable.** The [Catalog Overview → Popular column](/features/data-discovery/catalog-overview.md#recommended) ranks entities by view count alone, highest first. View count is bumped on every detail-page fetch with no rate limit, no per-user de-duplication, and no authentication required, and on a deployment with authentication disabled (`auth.type=DISABLED`) both the detail-page read and the `GET /api/dataentities/popular` endpoint are reachable by any caller on the network. A short scripted read loop can therefore push any chosen entity to the top of the Popular column. Do not treat the view count or the Popular ranking as trustworthy usage evidence in audits or capacity decisions; cross-check against your own access logs. {% endhint %} ## Per-class panel matrix The set of panels and tabs visible on a detail page depends on the entity's **class** — the categorical taxonomy that drives every composition decision. A single entity can carry multiple classes (e.g. an ML training pipeline that is both `TRANSFORMER` and `ENTITY_GROUP`); each class contributes its own panels. | Class | Main-column stats panel | Tabs beyond Overview | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `SET` (Dataset) | Dataset structure card — column count, row count, source-side schema link. | Structure, Lineage, Test reports, History (when test runs exist), Linked entities, Discussions, Activity. | | `TRANSFORMER` (Job / Pipeline) | Sources and targets list, with unknown-source / unknown-target counts surfaced separately. | Lineage, History, Linked entities, Discussions, Activity. | | `TRANSFORMER_RUN` (Job run) | No main-column stats panel renders today — the parent transformer's panel does not propagate to its runs. Per-run details live in History. | Lineage, History (own row), Linked entities, Discussions, Activity. | | `CONSUMER` (Microservice / BI tool) | Input list and unknown-input count. | Lineage, Linked entities, Discussions, Activity. | | `INPUT` (Source data feed) | Output list and unknown-output count. | Lineage, Linked entities, Discussions, Activity. | | `QUALITY_TEST` | Suite name, suite URL, tested datasets, test parameters. | Test reports, History, Linked entities, Discussions, Activity. | | `QUALITY_TEST_RUN` | No main-column stats panel renders today — the parent quality test's panel does not propagate to its runs. Per-run reports live in History. | History, Linked entities, Discussions, Activity. | | `ENTITY_GROUP` (DEG) | Member list and the entity-group authoring affordances. | Group Lineage, Linked entities, Discussions, Activity. | | `RELATIONSHIP` (ERD) | Source / target endpoints, cardinality, and join semantics. | Linked entities, Discussions, Activity. | For the canonical class taxonomy and how collectors assign classes during ingestion, see [Main Concepts → Data Entity Class](/introduction/main-concepts.md). {% hint style="warning" %} **An entity may render no main-column stats panel — silently — for two distinct reasons.** First, if the entity's class array is empty, undefined, or contains a value the UI does not recognise. Second, if the entity is one of the **run** classes (`TRANSFORMER_RUN` or `QUALITY_TEST_RUN`) — both are recognised enum values but the panel switch has no case for them, so they fall through to the default no-render branch. In either case the rest of the Overview (Description, Attachments, Metadata, sidebar panels) still loads, but the class-specific summary block is absent with no visible placeholder. When an Overview is missing its expected stats panel, first check the per-class matrix above (run-classes are expected to be empty here); if the class is none of the run-classes, check the entity's class assignment at the collector — that is the most likely cause. {% endhint %} {% hint style="warning" %} **The right-column Data Quality section is hidden when a dataset has zero test reports — and when the report is still loading.** The DQ panels appear only when the entity is a dataset AND its test-report total is non-zero. A dataset with no quality tests configured renders no DQ section. A dataset whose test-report fetch is still in flight also renders no DQ section. Both states produce the same empty space in the sidebar; the only way to tell them apart today is to wait and re-check, or to inspect the network tab. Treat sidebar DQ absence as "no tests **or** still loading" rather than as a confirmed "this dataset has no quality coverage" signal. {% endhint %} ## Class and type badges The detail-page header renders the entity's class taxonomy as a row of badges next to the name: * **Class badges** — one chip per entry in the entity's class array. Each chip is colour-coded per class (palette resolved from the platform's UI theme — the colour identifies the class at a glance once you've learned the mapping). Hovering a badge surfaces the canonical class label (the short label is on the chip; the longer "normal" label is in the tooltip). * **Type badge** — one chip immediately to the right of the class badges, showing the entity's specific type (`TABLE`, `VIEW`, `JOB`, `DASHBOARD`, `ML_MODEL_TRAINING`, etc.). The type label is the formatter-stripped underscore-free upper-case form of the underlying enum value. {% hint style="info" %} **Class is the load-bearing taxonomy; type is descriptive.** The class array drives every per-class composition decision on the page — which stats panel renders, which tabs are visible, whether the DQ sidebar appears. The type is a finer-grained descriptive label collectors set alongside the class; it does not gate UI surfaces today. {% endhint %} A few operator-visible behaviours of the badge row to be aware of: * **No tooltip explains per-class consequences.** A badge names the class (e.g. `Dataset`, `Transformer`) but does not say "this class is why you see a Structure tab" or "this class is why this entity has source/target panels." The mapping is in [Per-class panel matrix](#per-class-panel-matrix) above; the header surface does not surface it directly. * **The type badge is not colour-coded.** Class badges use per-class colours; the type badge uses a uniform background regardless of type. A dense list (search results, directory list) is therefore class-coloured but type-uniform — operators scanning a list distinguish entities by class colour at a glance, by type only after reading the label. * **An entity with no recognised class renders no class badge — silently.** Combined with the matching stats-panel absence noted above, an unclassified entity is structurally indistinguishable from an entity whose class payload was lost in transit. If the badge row shows only a type badge and no class chips, treat the entity as ingestion-incomplete and check the collector. * **Multi-class entities overflow horizontally.** The badge row uses no-wrap layout, so an entity carrying four or more classes overflows the horizontal allocation rather than wrapping to a second line. In practice multi-class entities are uncommon; an ML model that is both `ENTITY_GROUP` and `TRANSFORMER` is the canonical case. The "Edit business name" button shares the same row, so heavy class overflow can compress the visible name. * **The `DCT` type is a deliberate special case.** The type-name slot accepts the standard collector enum plus the literal string `'DCT'` — the dbt-cloud type, surfaced on the badge alongside the collector-side enum. If you see a `DCT` type on a `TRANSFORMER`-class entity, that is the [`odd-dbt`](/integrations/integrations/odd-dbt.md) push-adapter ingestion chain. ## Sidebar list truncation (Tags / Terms / Groups) The sidebar's **Tags**, **Terms**, and **Groups** panels cap visible items to keep the surface from stretching vertically. The cap is panel-specific and a `View All (N)` toggle expands the full list inline: | Panel | Initial visible | Toggle | | ---------- | -------------------------- | ----------------------------------------------------------------- | | **Tags** | First 20 tags | `View All (N)` button at the panel foot when the list exceeds 20. | | **Terms** | First 20 linked terms | Same. | | **Groups** | First 10 group memberships | Same. | The toggle's count suffix is the only visual signal that the panel has been truncated. An entity with exactly 20 tags shows a button-less footer; a 21-tag entity shows `View All (21)`. {% hint style="warning" %} **Tags ordering is not importance-stable across the truncation cap.** The Tags panel sorts by importance (important tags first) then alphabetically — but the sort runs **after** the cut to the first 20. An entity carrying more than 20 tags whose important ones happen to sit beyond the first 20 in collector-insertion order (for example: an operator tagged the entity once early, then added the important tags later) sees the visible window in raw insertion order, with the important tags missing from view; the user must click `View All` to find them. Mitigation: when you mark a tag important and expect it on the entity's at-a-glance strip, verify by opening the full list until the upstream fix lands. {% endhint %} {% hint style="warning" %} **The Groups and Terms panels' visible-window ordering is undefined.** Both panels apply a default sort with no comparator, which JavaScript resolves by stringifying each entry — yielding the same string for every object and leaving the order effectively as-received from the server. The Groups list (`DataEntityRef[]`) and the Terms list (`LinkedTerm[]`) share the same stringification defect. Display order in the visible 10 (Groups) or visible 20 (Terms) is collector-insertion order; do not rely on it being alphabetical or importance-based. {% endhint %} Within the visible window the truncation hint is the `View All (N)` button label only — visible items themselves do not fade or show a `+N more` tile to signal overflow before the click. ## Permissions surface Every editable panel on the Overview tab evaluates its own permission set locally. The detail page does not declare a single "what can I edit on this entity?" permission map — each panel is gated independently. | Panel | Permissions evaluated for edit affordance | | ----------------- | ------------------------------------------------------------ | | Description | `DATA_ENTITY_DESCRIPTION_UPDATE` | | Attachments | `DATA_ENTITY_ATTACHMENT_MANAGE` | | Metadata (custom) | `DATA_ENTITY_CUSTOM_METADATA_CREATE`, `…_UPDATE`, `…_DELETE` | | General — Owners | `DATA_ENTITY_OWNERSHIP_CREATE`, `…_UPDATE`, `…_DELETE` | | Groups | `DATA_ENTITY_ADD_TO_GROUP`, `DATA_ENTITY_DELETE_FROM_GROUP` | | Tags | `DATA_ENTITY_TAGS_UPDATE` | | Terms | `DATA_ENTITY_ADD_TERM`, `DATA_ENTITY_DELETE_TERM` | The page header carries its own per-affordance permission gates: | Header affordance | Permission | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Business name (Add / Edit) | `DATA_ENTITY_INTERNAL_NAME_UPDATE` | | [Status](/features/data-discovery/statuses.md) change | `DATA_ENTITY_STATUS_UPDATE` | | [Data Entity Group](/features/data-discovery/groups-domains.md) edit (manually-created groups only) | `DATA_ENTITY_GROUP_UPDATE` | | [Share to Slack](/features/active-platform-features/data-collaboration.md) | No separate permission — gated only by the `DATA_COLLABORATION` feature toggle. | When auditing "what does role X see on this entity," cross-reference each row of the two tables above against the role's permissions via [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md). The detail page does not surface the role-to-affordance map in the UI; the audit lives in the role definitions. When the entity's [status](/features/data-discovery/statuses.md) is `DELETED`, several Overview-tab and header edit affordances are hidden regardless of the operator's permissions — soft-deleted entities are read-only in the UI until the status is reverted. See [Data Entity Statuses → DELETED-state read-only surface](/features/data-discovery/statuses.md) for the per-affordance breakdown. ## Where to next * [Catalog Overview page](/features/data-discovery/catalog-overview.md), [Search](/features/data-discovery/search.md), [Directory](/features/data-discovery/directory.md) — the three discovery entry paths that land an operator on this page. * [Entity description](/features/data-discovery/entity-description.md), [Custom metadata](/features/data-discovery/custom-metadata.md), [Per-column annotation](/features/data-discovery/per-column-annotation.md), [Manual Object Tagging](/features/data-discovery/tagging.md), [Business names](/features/data-discovery/business-names.md), [Data Entity Statuses](/features/data-discovery/statuses.md), [Data Entity Groups & Domains](/features/data-discovery/groups-domains.md), [Data Entity Attachments](/features/data-discovery/attachments.md), [Metadata stale](/features/data-discovery/metadata-stale.md) — per-aspect deep dives for the panels and header affordances on this page. * [Data Lineage](/features/data-lineage.md) — the Lineage tab on every entity detail page (class-dependent visibility). * [Activity Feed](/features/active-platform-features/activity-feed.md) — the per-entity Activity tab; the audit trail for every change applied through this surface. * [Main Concepts → Data Entity Class](/introduction/main-concepts.md) — the canonical class taxonomy whose enum values drive every per-class composition decision above. * [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md) — the role-definition surface where the per-affordance permissions on this page resolve. * [Data Discovery overview](/features/data-discovery.md) — the bucket landing this page sits under. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opendatadiscovery.org/features/data-discovery/entity-detail-page.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.