Management

Management — the operator-facing surface for everything an operator configures inside the platform UI. One landing per tab; nine tabs total covering data sources, integrations, collectors, ownership,

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 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 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.
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 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.
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 and Permissions for the available permission keys.

The whole section is gated behind the platform's authentication. 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.

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.

• 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.

• 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.

• Integration Wizard — 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 section.

• For the user-facing Catalog counterpart — search, the Directory, the Catalog Overview page — see the Data Discovery pillar.

• For the operator's first-run path (deploy the platform, deploy a Collector, register a source) — see Try locally and the Configure ODD Platform reference.

• For the integration template registry that the Integrations tab consumes — see the Integration Wizard page.

• For the API surface behind the Integrations tab — see API Reference → Integrations.