> 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/statuses.md). # Data Entity Statuses Every catalogued entity carries a **status** that signals where it is in its lifecycle — newly ingested, in active use, deprecated for a planned removal, or soft-deleted pending permanent purge. The status is operator-set, surfaces on the Catalog page as a [Search facet](/features/data-discovery/search.md), and drives the [Activity Feed](/features/active-platform-features/activity-feed.md)'s `DATA_ENTITY_STATUS_UPDATED` event. ## The five statuses | Status | Meaning | Set by | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **`UNASSIGNED`** | The default. When metadata collectors ingest data entities into the platform's database, every new entity lands as `UNASSIGNED` until an operator changes it. | Platform default; can be operator-overridden via the entity detail page. | | **`DRAFT`** | The data entity is a draft / test entity in the data source — not yet ready for downstream consumption. The UI lets operators set a time period after which the status auto-transitions to `DELETED`. | Operator. | | **`STABLE`** | The data entity is stable and fully operational — safe for downstream pipelines and BI reports. | Operator. | | **`DEPRECATED`** | A warning marker — the entity is deprecated for planned removal. The UI lets operators set a time period after which the status auto-transitions to `DELETED`. | Operator. | | **`DELETED`** | Soft-deleted. The entity is hidden from the [Management → Datasources](/features/management.md) view by default and only reachable through filter-with-deleted-items. | Operator (manual) or auto-transition from `DRAFT` / `DEPRECATED` after the TTL window expires. |

Default status on newly-ingested entities

Operator changes the status from the entity detail page

## The soft-delete TTL `DELETED` is **soft delete**. The platform's housekeeping job permanently deletes a `DELETED` entity (and every cascading row attached to it — metadata values, ownerships, lineage, tags, terms, alerts, messages, metrics, **attachment files including objects in S3 / MinIO storage**, task runs, group relations, and dataset structure / enum values for datasets) only after the entity's status-update timestamp is older than `housekeeping.ttl.data_entity_delete_days`. The default window is **30 days**. During the soft-delete window the operator can flip the status back (`DELETED` → `STABLE` or any non-deleted status) and the entity reappears in the catalog with its history intact. After the TTL expires the next housekeeping run hard-deletes the row; once that happens, recovery requires re-ingest from the source. To change the retention window, see [Housekeeping Settings Configuration → `housekeeping.ttl.data_entity_delete_days`](/configuration-and-deployment/odd-platform.md#housekeeping-settings-configuration). Raise the value before any planned bulk deprecation if the audit trail matters for compliance. {% hint style="danger" %} **The 30-day purge is permanent and cascades to object storage — `DELETED` is not long-term parking.** On a default install (`housekeeping.enabled: true`, `housekeeping.ttl.data_entity_delete_days: 30`), once a `DELETED` entity's status-update timestamp is older than the configured window, the next housekeeping run **hard-deletes** it: the `data_entity` row, its cascading rows across the child tables (lineage, metadata, ownerships, tags, terms, alerts, messages, metrics, task runs, group relations, and dataset structure / enum values), **and its attachment files in object storage — including objects in S3 / MinIO**. There is **no restore path** once this runs; recovering the entity means re-ingesting it from its source. Do **not** treat `DELETED` as an archive or a recycle bin. The restore-by-flipping-status escape hatch works **only within** the retention window — after the window elapses the entity and its attachments are gone. To retire entities but keep them recoverable for longer, raise `housekeeping.ttl.data_entity_delete_days` (or disable the housekeeping job) **before** parking anything in `DELETED`. See [Housekeeping Settings Configuration](/configuration-and-deployment/odd-platform.md#housekeeping-settings-configuration) for the key and the partial-override risk that can shrink the window to zero. {% endhint %} {% hint style="info" %} **Known defect — the `status_updated_at` timestamp is not refreshed on non-`DELETED` status transitions.** A guard in the platform's status mapper (`DataEntityMapperImpl.applyStatus`) tests the new status id against a value it has just overwritten with that same id, so the branch that re-stamps `status_updated_at` never runs. The timestamp is therefore left unchanged when an entity moves between `DRAFT` / `STABLE` / `DEPRECATED` or is restored from `DELETED`. This is cosmetic and does **not** affect the soft-delete retention clock above: the transition **to** `DELETED` runs through a separate soft-delete code path that stamps `status_updated_at` correctly, so the 30-day purge always measures retention from the actual deletion time. {% endhint %} {% hint style="warning" %} **Known limitation — the scheduled DRAFT / DEPRECATED → DELETED auto-flip has no per-tick batch cap.** When an operator schedules a future status switch (the `auto-transition to DELETED after N days` affordance on `DRAFT` and `DEPRECATED`), the platform records `status_switch_time` on the entity and a background job picks up every entity whose `status_switch_time` is in the past and flips it. The job fires every **10 minutes** under a **9-minute distributed lock** (ShedLock), and the underlying query selecting candidate entities has **no `LIMIT`** — every overdue entity is processed in a single transaction. A bulk operation that schedules (say) 5,000 entities for a near-future flip triggers one transaction processing all 5,000 pojos plus their cascade fan-out. If the transaction runs longer than the 9-minute lock window, the lock releases mid-flight, the next tick acquires its own lock, and the effective cadence drifts from "every 10 minutes" to "as fast as one large transaction can finish." There is no per-batch metric or operator-side dial to throttle it. When scripting bulk `DRAFT` / `DEPRECATED` assignments with auto-transition, stagger `status_switch_time` values across multiple windows (e.g. spread 5,000 entities across 50 ten-minute windows of 100 each) to avoid the burst. A platform-side per-tick `LIMIT` is on the roadmap. {% endhint %} ## Status changes propagate to data sources If the status of a data entity **and its parent data source** are both set to `DELETED` and an operator then flips the entity status back to a visible state, the data source itself reverts to its original (non-deleted) condition. The platform mirrors entity-level status changes back up the data-source row when the two are in lockstep. ## DELETED-state read-only surface When an entity's status flips to `DELETED`, the platform makes it intentionally read-only in the UI. Several edit affordances disappear from the detail page in the same render — silently, without an info banner — until the status is flipped back to a non-deleted state. The affordances hidden in `DELETED` state: | Affordance | Location | | --------------------------------------------------------- | -------------------------------------------- | | **Add / Edit business name** | Detail-page header, next to the entity name. | | **Edit group** (manually-created Data Entity Groups only) | Detail-page header, right-hand action strip. | | **Edit tags** | Overview tab → Tags sidebar panel. | | **Add to group** | Overview tab → Groups sidebar panel. | The entity name, the class / type badges, the [status](/features/data-discovery/statuses.md) badge, the [Share to Slack](/features/active-platform-features/data-collaboration.md) button (when [Data Collaboration](/features/active-platform-features/data-collaboration.md) is enabled), the read-only data on every panel, and every tab below the header all continue to render normally. {% hint style="info" %} **To edit a `DELETED` entity, restore it first.** Soft-deleted entities are intentionally read-only — the platform hides the edit affordances rather than letting an operator modify a record that is queued for permanent deletion. Flip the status back to `STABLE`, `DRAFT`, or `DEPRECATED` from the status badge (the badge itself is always interactive for users with the `DATA_ENTITY_STATUS_UPDATE` permission, even in `DELETED` state); the hidden affordances reappear in the next render. {% endhint %} The same read-only treatment applies when the soft-delete TTL has not yet expired — see [The soft-delete TTL](#the-soft-delete-ttl) above. Once the TTL elapses and the housekeeping job hard-deletes the row, the detail page itself returns a 404; restoring is only possible during the soft-delete window. ## Detail-header authoring caveats A few smaller behaviours on the detail-page header that are non-obvious on first encounter: * **The business-name button toggles its label between "Add business name" and "Edit".** Both labels open the same dialog. If the entity has no `internalName` set, the button reads `Add business name`; once one is set, it reads `Edit`. Train teammates to look for either label rather than only `Add business name`. The Overview tab's Tags row follows the same pattern (`Add tags` vs `Edit tags`). * **The status badge renders identically for users without `DATA_ENTITY_STATUS_UPDATE` — but clicking it does nothing.** The badge has no lock icon, no `cursor: not-allowed`, and no "you can't change this" tooltip; non-permission holders see the same chip everyone else does and discover they can't interact with it by clicking. If your deployment uses strict RBAC, grant `DATA_ENTITY_STATUS_UPDATE` explicitly to the roles that should change status — see [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md). * **The "Share" button is silently absent unless Data Collaboration is enabled.** The Slack share affordance is gated by the `DATA_COLLABORATION` feature toggle (default off). When the toggle is off the button is unmounted entirely — no "feature disabled" placeholder, no install hint. After enabling [Data Collaboration](/features/active-platform-features/data-collaboration.md), the button appears on every entity detail page in the next page load. ## Group statuses Status assignments apply to entity **groups** as well as individual entities. When an operator changes a status on a [Data Entity Group](/features/data-discovery/groups-domains.md), the UI offers the option to apply the change to the group as a whole or to cascade it to every member entity. Use the group-level status when you want to deprecate or retire an entire pipeline; use member-level when only specific members are affected.

Group-level status assignment

Apply-to-group vs apply-to-members confirmation

## Where the status surfaces * **Catalog page filter** — Statuses is one of the seven [Search facets](/features/data-discovery/search.md). Selecting one or more statuses narrows the result set to entities matching any of them.

Statuses facet on the Catalog page

* [**Activity Feed**](/features/active-platform-features/activity-feed.md) — every status change emits a `DATA_ENTITY_STATUS_UPDATED` event. The feed is the audit trail for who set what status and when.

Status-update event on the Activity feed

* **Entity detail page** — the current status is shown next to the entity name, with edit affordance gated by the `DATA_ENTITY_STATUS_UPDATE` permission (see [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md)). ## RBAC Operators need the `DATA_ENTITY_STATUS_UPDATE` permission to change a data entity's status. The permission is part of the Data entity permissions group; see [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md) for the full list and how to compose roles around it. ## Where to next * [Search and Filtering](/features/data-discovery/search.md) — the Statuses facet that surfaces these on the Catalog page. * [Activity Feed](/features/active-platform-features/activity-feed.md) — the audit trail of every status change (`DATA_ENTITY_STATUS_UPDATED`). * [Data Entity Groups & Domains](/features/data-discovery/groups-domains.md) — the group-vs-member status apply-to choice. * [Data entity detail page](/features/data-discovery/entity-detail-page.md) — the composition of the detail page that hosts every header affordance documented above. * [Housekeeping Settings Configuration](/configuration-and-deployment/odd-platform.md#housekeeping-settings-configuration) — the soft-delete TTL operator-side reference. * [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md) — the `DATA_ENTITY_STATUS_UPDATE` permission. * [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/statuses.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.