Skip to content

Promote Types

Qualytics supports four types of promote operations, each designed for a specific asset type and scope. This page provides a detailed comparison to help you understand when and how to use each type.

Overview

Quality Checks Computed Fields Computed Tables Computed Files
Scope Container → Container Container → Container Datastore → Datastore Datastore → Datastore
Destination constraint Any container Any container JDBC datastores only DFS datastores only
Selection methods All, specific, or by tag All, specific, or by tag All, specific, or by tag Specific only
Matching strategy Overlap (rule type + fields + properties) Name Name (includes deleted) Name (includes deleted)
Draft option Yes No No No
Post-promote profile No Yes (slim profile) Yes (full profile) Yes (full profile)
Mapping step No No No Yes (file pattern mapping)
Modal steps 2 2 2 3

All promote types share the same permission gate: Editor team permission on both source and destination. See Permissions for details.

Quality Check Promotion

Quality check promotion copies check definitions from one container to another. It operates at the container level, meaning you select a source container and a destination container, which can be on the same or different datastores.

Key Behaviors

  • Source filter — Active and Draft only: The platform automatically excludes checks in Discarded or Archived status, even when they are explicitly listed by ID. Only Active and Draft checks are eligible for promotion.
  • Field mapping by name: Source check fields are matched to destination container fields by name. Destination fields with status excluded or missing are treated as if they did not exist. If no required field can be mapped, the check is promoted as Draft with empty fields and a warning describing the unresolved mapping.
  • Overlap-based matching: When no record of a previous promotion exists, the platform matches checks by semantic overlap — same rule type, fields, rule-specific properties, and filter expression. See Entity Matching for the exact comparison rules.
  • Draft mode: You can promote checks as Draft (default, as_draft=true) or Active. When promoted as Active, checks undergo validation against the destination before activation. Validation runs in batches of 10. If validation rejects a check, the just-created destination row is removed and the source check is recorded as failed — no orphan check is left behind.
  • Tag preservation: Tags from source checks are carried over to the destination, plus any additional tags you specify.

Where to Trigger

  • Container menu: Settings > Promote > Quality Checks
  • Individual check: Context menu > Promote (skips selection step)

Computed Field Promotion

Computed field promotion copies computed field definitions from one container to another. It operates at the container level.

Key Behaviors

  • Source field resolution: The source fields referenced by the computed field are resolved by name on the destination container. All referenced fields must exist and be in an eligible status (not excluded or missing).
  • Dependency auto-inclusion: When you select a computed field that references other computed fields — either through explicit source_fields or through field references inside a custom expression — the platform expands the selection to include every transitive dependency. This means promoting a single nested computed field can pull in its parent computed fields automatically.
  • Topological execution order: Selected computed fields are processed parents-first, so each field's dependencies are already in place on the destination by the time it is created. The slim profile that follows generates field metadata for the new fields in the same order.
  • Circular dependency detection: If the dependency graph contains a cycle, the request is rejected up front with a 422 error listing the cycle members. Circular dependencies fail validation before the operation is enqueued — not asynchronously.
  • Name-based matching: Existing computed fields on the destination are matched by name.
  • Rename propagation: If a previously promoted computed field has been renamed at the source, the destination field name is updated to match. The rename also cascades to the underlying field record and its latest field profile, so downstream references stay aligned.
  • Name collision detection: If a regular (non-computed) field with the same name exists on the destination, the promotion fails for that field.
  • Slim profile: After promotion, a slim profile runs on the destination container to generate field metadata for the new computed fields. If this profile fails, all promoted fields are marked as failed.
  • Field reactivation: If a previously excluded destination computed field is being re-promoted, it is reactivated to Active status.
  • Dependency-aware error message: When a source field cannot be resolved on the destination, the failure message includes a hint that the parent computed field may have failed to promote — useful when debugging a chain of related failures.
  • Tags: Only the additional tags supplied on the request are applied to the promoted computed field (applied to the generated Field row after the slim profile completes). Source field tags are not carried over.

Where to Trigger

  • Container menu: Settings > Promote > Computed Fields
  • Individual field: Context menu > Promote (skips selection step)

Computed Table Promotion

Computed table promotion copies computed table definitions from one datastore to another. It operates at the datastore level, creating new containers on the destination datastore.

Key Behaviors

  • JDBC only: The destination must be a JDBC datastore.
  • Definition copied: The query, incremental identifier, group-by fields, and tracking settings (volumetric, freshness) are replicated.
  • Profile after creation: A profile operation runs on each created or updated computed table.
  • Tag inheritance: New tables receive the destination datastore's global tags (excluding any with type=external) plus any additional tags specified on the request. Source tags are not carried over — the destination-side tag context defines what a new table inherits.
  • Includes deleted: The matching logic includes soft-deleted containers, so previously deleted tables can be reactivated.
  • Type mismatch fails the entity: If a regular (non-computed) table already exists on the destination with the same name, the promotion fails for that entity with a type-mismatch message.

Where to Trigger

  • Datastore menu: Settings > Promote > Computed Tables
  • Individual container: Context menu > Promote > Computed Table (skips selection step)

Computed File Promotion

Computed file promotion copies computed file definitions from one datastore to another. It operates at the datastore level and includes a unique mapping step.

Key Behaviors

  • DFS only: The destination must be a DFS datastore.
  • Mapping required: Each source computed file must be explicitly mapped to a profiled file pattern on the destination datastore. This is done in a dedicated mapping step.
  • Auto-match: The platform offers fuzzy name matching to suggest mappings automatically, with confidence scores displayed for each suggestion.
  • No tag-based selection: Unlike other promote types, computed files can only be selected individually — tag-based selection is not supported.
  • Profiled destination required: The destination datastore must have at least one profiled file pattern container. Each destination container in the mapping is checked to confirm it has been profiled — otherwise the request returns a 422 error before any work is enqueued.
  • Profile after creation: A profile operation runs on each created or updated computed file.
  • Tag inheritance: New computed files receive the destination datastore's global tags (excluding any with type=external) plus any additional tags specified on the request. Source tags are not carried over — the destination-side tag context defines what a new computed file inherits.
  • Type mismatch fails the entity: If a regular (non-computed) file pattern already exists on the destination with the same name, the promotion fails for that entity with a type-mismatch message.

Where to Trigger

  • Datastore menu: Settings > Promote > Computed Files
  • Individual container: Context menu > Promote > Computed File (skips selection step)