Skip to main content

​
Metadata Ingestion - Hierarchical Owner Configuration

The Hierarchical Owner Configuration (ownerConfig) lets you assign owners to databases, schemas, and tables as Collate ingests them, without depending on an owner being set in the source system. Set a single owner for an entire level, map specific entities to specific owners, or let child entities inherit an owner from their parent when they don’t have a match of their own. In the UI, this appears as the Agent Setup fields Default, Service, Database, Database Schema, Table, and Enable Inheritance when configuring a Metadata Agent. This is different from the Include Owners toggle, which only pulls in an owner if the source system already reports one for that entity.

​
How Resolution Works

For each database, schema, and table Collate ingests, it resolves an owner in this order:
  1. Exact mapping: If the level’s configuration is a map, Collate looks for the entity’s fully qualified name first, then falls back to matching on the entity’s simple name.
  2. Level default: If the level’s configuration is a single value instead of a map, that owner applies to every entity at that level.
  3. Inherited owner: If nothing matched at the current level and enableInheritance is true (the default), the entity inherits the owner already resolved for its parent. A schema inherits from its database, and a table inherits from its schema, or from its database if the schema itself has no resolved owner.
  4. Default owner: If nothing above resolved an owner, Collate falls back to the top-level default value.
If none of these steps resolve an owner, the entity is ingested without one.
The schema also defines a service field (the Service field in Agent Setup), but it isn’t applied during ingestion. Only database, databaseSchema, and table level configuration affects the resolved owner. Setting service has no effect.

​
Configuring via YAML

Add ownerConfig under sourceConfig.config in your ingestion YAML:
  • default: Fallback owner (a user or team name, or an email) applied when nothing more specific matches at any level.
  • database: Owner for database entities. Either a single owner applied to every database, or a map of database names to owner(s).
  • databaseSchema: Owner for schema entities. Either a single owner applied to every schema, or a map keyed by the schema’s fully qualified name (database.schema) or simple name, mapped to owner(s).
  • table: Owner for table entities. Either a single owner applied to every table, or a map keyed by the table’s fully qualified name (database.schema.table) or simple name, mapped to owner(s).
  • enableInheritance: When true (default), a schema or table without its own match inherits the resolved owner from its parent instead of falling straight to default.

​
Assigning Multiple Owners

A mapped owner value can be a single name or a list:
  • Multiple users are allowed in a list.
  • Only one team is allowed as an owner, and it can’t be combined with users or other teams in the same list.
  • Each value must be a user or team name, or email, already registered in Collate. Values that can’t be resolved are skipped, and the entity is ingested without that owner.

​
Precedence with Include Owners

ownerConfig and Include Owners are independent settings: enabling or disabling Include Owners doesn’t affect whether ownerConfig’s rules apply, and ownerConfig doesn’t need Include Owners enabled to work. For tables, ownerConfig is resolved first. If it doesn’t produce an owner and Include Owners is enabled, Collate falls back to the owner reported by the source system. On entities that already exist in Collate and already have an owner, a resolved owner from ownerConfig doesn’t overwrite it unless Override Metadata is also enabled, the same way that setting governs description, tags, and display name elsewhere in this pipeline.

​
Feature Available For

Hierarchical Owner Configuration is available for all database connectors, since it’s part of the shared Database Metadata Pipeline configuration.