# Management The **Management** section is the operator-facing surface inside the platform UI: every tab here lets an operator add, edit, or remove a piece of catalog configuration. Where the Catalog and the [Directory](/features/data-discovery/directory.md) are read-oriented (a user finds an existing entity), Management is mutating (an operator changes how the catalog is wired). Most operator workflows after the platform is running — registering a data source, issuing a collector token, granting roles, managing owners, curating tags — start here. Open it from the top-level navigation **Management**. The page renders a vertical tab sidebar on the left (one entry per Management area) and a content pane on the right; clicking a sidebar entry navigates to `/management/{tab}` and mounts the corresponding sub-page. ## What is in Management The nine Management tabs (in their UI order, from `ManagementTabs.tsx`): | Tab | Path | What it manages | Typical workflow | | ---------------- | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Namespaces** | `/management/namespaces` | Logical groupings used to scope tags, terms, and other taxonomy concepts. Acts as a label dimension applied across the catalog. | Create a namespace before authoring tags or terms that should be scoped to a particular team or domain. | | **Datasources** | `/management/datasources` | Registered data sources — the platform's view of every system a Collector or Push-client is reporting from. View existing sources, audit ingestion timestamps, edit metadata, link to a Collector + Namespace. | Inspect what was registered after a Collector first reported; add a description / tag a source; remove a source no longer ingested. | | **Integrations** | `/management/integrations` | The Integration Wizard surface — pick an integration template, fill in its parameters, and copy the generated `collector_config.yaml` snippet. | Generate a working snippet for a new pull adapter; wired-up template registry is documented at the [Integration Wizard](/integrations/integrations/integration-wizard.md) page. | | **Collectors** | `/management/collectors` | Registered Collectors and their tokens. Issue new tokens, view existing token IDs, regenerate or revoke. | Issue a token before deploying a Collector; rotate a leaked token; remove a Collector that's been retired. | | **Owners** | `/management/owners` | Owner entities — the catalog-side identity that gets associated with users and attached to data entities for stewardship. | Create owners that map to teams or individuals; attach them to data entities (the attach surface is on each entity's page). See [Owners](/configuration-and-deployment/enable-security/authorization/owners.md). | | **Tags** | `/management/tags` | The catalog's tag taxonomy. Tags can be marked **important** (rendered visually distinct) and namespace-scoped. | Curate a stable tag vocabulary so search facets and filters stay coherent. | | **Associations** | `/management/associations` | Pending requests from signed-in users to be associated with an Owner. Approve / reject. **Hidden unless the signed-in user has the `OWNER_ASSOCIATION_MANAGE` permission.** | Process new-user association requests; see [User-owner association](/configuration-and-deployment/enable-security/authorization/user-owner-association.md) for the request flow. | | **Roles** | `/management/roles` | Named RBAC roles — bundles of policies applied to users (or owners) to grant catalog-side permissions. | Create roles (`Editor`, `Reader`, `Owner-of-Domain-X`) and attach Policies to them. See [Roles](/configuration-and-deployment/enable-security/authorization/roles.md). | | **Policies** | `/management/policies` | Permission rules — the building blocks of RBAC. Each Policy defines who-can-do-what on resources matched by ODDRN patterns (or per-feature surfaces like Lookup Tables, Query Examples, Owner Association). | Define fine-grained access (e.g. "data engineers can edit transformer entities under prefix `airflow://...`"). See [Policies](/configuration-and-deployment/enable-security/authorization/policies.md) and [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md) for the available permission keys. | The whole section is gated behind the platform's [authentication](/configuration-and-deployment/enable-security/authentication.md). Tab visibility is permission-aware (Associations is the explicit case today; other tabs are visible to any signed-in operator and the per-tab actions enforce permission checks). ![Management → Datasources tab — every registered data source on a deployment, each card showing the source's ODDRN, description, namespace, and a partially-redacted Collector token with a Regenerate action. The vertical sidebar lists every Management area (Namespaces, Datasources, Integrations, Collectors, Owners, Tags, Associations, Roles, Policies); the + Add datasource button at the top-right is the entry-point for registering a source the operator wants to ingest.](/files/DtdpA9IgBCzHD3tpJL7S) ## Other Management surfaces Beyond the in-app Management tabs, several operator-facing controls live on the platform's authentication, configuration, and collector-secrets surfaces. They are part of how an operator manages the system, even though they don't render as a Management UI tab today: * **Machine-to-Machine (M2M) tokens** — Server-to-server (S2S) API key authentication for non-UI programmatic callers (CI/CD jobs, ingestion pipelines, automation scripts). Disabled by default; configured on the platform's auth surface — see [Server-to-server (S2S) authentication](/configuration-and-deployment/enable-security/authentication/s2s.md). * **Custom navigation links** — the App Info menu items (top-right toolbar) that surface to every signed-in user. Configured via `odd.links[]` on the platform side — see [Configure ODD Platform → Additional navigation links](https://docs.opendatadiscovery.org/features/pages/YH2ILihhfTPfYTyBhtw2#additional-navigation-links-odd.links). * **Alternative Secrets Backend** — store collector configuration (Platform tokens, plugin credentials) in AWS SSM Parameter Store instead of plaintext in `collector_config.yaml`. Configured on the collector deployment — see [Collector secrets backend](/configuration-and-deployment/collectors-secrets-backend.md). * [**Integration Wizard**](/integrations/integrations/integration-wizard.md) — the in-app generator for `collector_config.yaml` snippets that backs the **Integrations** tab above; handy when bootstrapping a new pull adapter without hand-authoring the YAML. ## Audience and typical sequencing The audience is **operators** — people who run an ODD deployment for their team. A typical first-deployment sequence touches several Management tabs in order: 1. **Namespaces** — create the logical groups (per team, per domain) you'll scope tagging and term curation to. 2. **Datasources** — verify that the first Collector has registered its sources after the initial ingest. 3. **Collectors** — issue a token and configure additional Collectors as more sources come online. 4. **Owners** — create the catalog-side owner entities for teams and individuals. 5. **Roles + Policies** — author the RBAC bundles that fit the operator's organisation, then attach roles to owners. 6. **Tags** — start curating the tag vocabulary as ingest expands. 7. **Integrations** (as needed) — generate per-integration snippets via the wizard when adding new pull adapters. 8. **Associations** — process incoming requests as users self-associate to owners. Daily-operations workflows tend to live on tabs 2 (Datasources audit), 4 (Owners maintenance), 5 (RBAC tweaks), and 8 (Associations queue). ## Where to next * For per-tab security model — RBAC building blocks, the permission keys, and the request flow for owner association — see the [Authorization](/configuration-and-deployment/enable-security/authorization.md) section. * For the user-facing **Catalog** counterpart — search, the Directory, the Catalog Overview page — see the [Data Discovery](/features/data-discovery.md) pillar. * For the operator's **first-run** path (deploy the platform, deploy a Collector, register a source) — see [Try locally](/configuration-and-deployment/trylocally.md) and the [Configure ODD Platform](/configuration-and-deployment/odd-platform.md) reference. * For the integration template registry that the **Integrations** tab consumes — see the [Integration Wizard](/integrations/integrations/integration-wizard.md) page. * For the API surface behind the **Integrations** tab — see [API Reference → Integrations](/developer-guides/api-reference/integrations.md). --- # Agent Instructions: 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/management.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.