Getting Started with Promote

Promote is an operation that copies data quality assets from a source location to a destination location within the Qualytics platform. It acts as a replication mechanism for quality checks, computed fields, computed tables, and computed files, so you can build quality rules once and apply them across your data ecosystem.

In this section you will learn the role promote plays in data quality, how it supports standardization and change management across environments, where in the app you can start a promotion, practical scenarios for each promote type, and best practices for safe rollouts. Every promote type uses the same access gate: Editor team permission on both the source and the destination. See Permissions for details.

The Role of Promote in Data Quality

In any data quality program, teams need to apply consistent rules across multiple datasets. A quality check that validates email formats in one table should work the same way in every table that contains email addresses. A computed field that normalizes dates should produce the same transformation wherever it's used.

Rather than recreating these assets manually in each location, Qualytics uses promote to:

• Distribute quality standards. Promote quality checks from a reference container to every container that shares the same field structure, ensuring uniform validation rules.
• Replicate transformations. Promote computed fields, tables, and files from one environment to another, keeping derived data consistent across datastores.
• Push updates downstream. When a quality check is refined at the source, re-promoting it finds the destination produced by the previous promotion and updates it in place. See Entity Matching.
• Enable environment workflows. Build and test quality rules in development, then promote them to staging and production with confidence.

How Promote Supports Data Quality

Standardized Quality Rules

By promoting quality checks from a reference container to other containers, you ensure that the same validation rules apply everywhere. This eliminates drift between environments and reduces the risk of inconsistent quality standards.

For example, if your team maintains a set of quality checks on a canonical customers table, you can promote those checks to every customers table across your datastores, in development, staging, and production alike.

Efficient Computed Asset Management

Computed fields, tables, and files often represent significant engineering effort. Promote allows you to define these assets once and replicate them wherever they're needed, avoiding redundant work and ensuring that all environments use the same transformation logic.

Change Management

When you update a quality check or computed field at the source, re-promoting it to the same destination updates the existing entity rather than creating a duplicate. The platform looks up the destination produced by the previous promotion and updates it in place, even if it has been renamed since. See Entity Matching for the full strategy.

Audit Trail

Every promote operation records detailed metadata: which entities were promoted, from where to where, what the result was (created, updated, skipped, or failed), and who triggered the operation. This provides a clear audit trail for compliance and troubleshooting.

Where You Can Start a Promote

Promote is reachable from several places, and every one of them opens the same modal. The difference is only how much of the modal is filled in for you.

The card and list item shortcut covers quality checks, computed fields, computed tables, and computed files. Promote requires the Editor team permission, so these menus and actions are hidden from users below that level. Editor is needed on both the source and the destination for the promotion itself to go through, which is why a promotion can still be refused after you pick a destination you do not have Editor on.

Promote in Bulk Selection

When you tick assets on a list page, the selection bar shows a single Promote action carrying that asset's own icon, rather than a generic submenu you have to open first. Only one asset type can be promoted at a time, so the action behaves like this:

• Available when everything you selected is the same promotable type.
• Visible but greyed out when your selection mixes types, or spans more than one table. Hovering it shows a short reason, such as "Only computed fields can be promoted" or "Checks from different tables can't be promoted together".
• Hidden when nothing you selected can be promoted at all, or when you lack the Editor team permission.

Showing the action greyed out with a reason, instead of removing it, means you can tell the difference between "promote does not apply here" and "promote is not possible with this particular selection".

Operation Lifecycle

Promote runs in the background, and the platform makes a few guarantees about how an operation behaves over its lifetime:

• You land on the operation automatically. After you submit a promotion, the modal confirms that the operation was triggered, and closing that confirmation takes you straight to the operation's page. You no longer have to find the run yourself on the Activity page. This applies to every promote type and every entry point.
• Resumable on retry. If a run is interrupted and then retried, the platform skips entities that have already been processed. Previous failed results for the same entity are replaced by the new attempt rather than duplicated. A restart never produces double promotions or partial duplicates.
• Abortable mid-run. A running promote operation can be aborted from the Activity page. It stops cleanly between entities, so anything already processed keeps its result and the operation is marked as aborted.
• Per-entity failures do not stop the operation. A promotion is reported as success if at least one entity is created, updated, or skipped. Individual entity failures are surfaced in the per-entity result list. The operation only reports failure when every entity in the request fails.
• Source and destination must differ. A promote request returns an error if the source and destination resolve to the same container or datastore.

Practical Scenarios

For concrete data engineering scenarios, see the Use Cases page. It covers multi-tenant onboarding, environment rollouts, warehouse migrations, schema versioning, cross-region replication, and DFS standardization.

Best Practices