How It Works¶

This page explains the mechanics behind the Export Operation: the asset types it supports, how containers are selected, where the data lands in your enrichment destination, how anomalies can be merged with their source records, how the operation runs asynchronously, the size limits that apply to each run, and what happens when you re-run it.

Asset types¶

Each Export Operation captures one asset type per run, chosen at the modal's Choose step:

The exported columns differ by asset type. See Export Schema for the full column list of each.

An Anomalies export can also be merged with its source records, which writes a separate _export_anomaly_records output. See Merge with Source Records.

Container selection¶

You decide which containers (tables, files, or views in the source datastore) the export covers:

The three modes are mutually exclusive: pick one per operation.

Where the data lands¶

The exported data is written as an output in the linked enrichment destination, not as a browser download. The output name follows a fixed pattern:

_<sanitized-datastore-name>_export_<asset>

• <sanitized-datastore-name> is the source datastore's name with every non-alphanumeric character replaced by _, then lowercased.
• <asset> is anomalies, checks, or field_profiles (note: the Field Profiles asset uses the field_profiles suffix in the output name even though the API enum value is profiles).

Examples for a source datastore named "Acme Sales 2024":

• Anomalies output → _acme_sales_2024_export_anomalies
• Quality Checks output → _acme_sales_2024_export_checks
• Field Profiles output → _acme_sales_2024_export_field_profiles
• Anomalies merged with source records → _acme_sales_2024_export_anomaly_records

After the export, Qualytics adds the written containers to the destination, without a Sync. When Profile written tables in the enrichment destination is enabled on the writing datastore, Qualytics also profiles them. When it is disabled, their fields stay untyped until you run a Profile on the destination yourself. See What happens after each write.

Merge with Source Records¶

When you export Anomalies, the Merge with Source Records option writes each anomaly together with the source records it flagged, so you can see an anomaly's latest status beside the actual rows it was raised on. It writes to its own output, _<sanitized-datastore-name>_export_anomaly_records, which appears in Qualytics as Anomalies with Records (<datastore>), instead of the regular Anomalies output. A run with the option on leaves the regular Anomalies output as it was, so keep a run without the option if you rely on that output.

• One row per anomaly, failed check, and source record. An anomaly that failed two checks and has three source records is written as six rows. An anomaly with no source records is still written, once per failed check, with an empty RECORD.
• Check attribution. Each source record is repeated for every failed check on the anomaly. CHECK_ID identifies a failed check on that anomaly, but does not prove that the particular RECORD failed that check. For anomalies with multiple failed checks, do not use these rows as exact per-check record counts or as the sole basis for deciding which records to correct.
• Added columns. Each row carries the anomaly's regular export columns plus the failed check (CHECK_ID), the scan that raised the anomaly (SCAN_ID), its partition (SOURCE_PARTITION), when it was first identified (FIRST_IDENTIFIED_AT), and one source record as JSON (RECORD). See Export Schema.
• First identified. FIRST_IDENTIFIED_AT is the earliest CREATED among the anomalies on the same container that share the anomaly's fingerprint, whatever their status, so a repeated detection carries the date of its first occurrence. An anomaly with no earlier match has FIRST_IDENTIFIED_AT equal to CREATED.
• Source records come from the destination. Records are read from the source records output in the same enrichment destination when the export runs. An anomaly whose records are no longer there, or were never written, is exported with an empty RECORD.
• Masking. RECORD is written as the source records output stores it, and stays masked in Qualytics row previews. Profile histogram values are masked by default; users with the Editor team permission on the destination can explicitly reveal them. See Field Masking and Export.

Async execution model¶

The Export Operation runs asynchronously:

1. You trigger the export. The platform validates the request, creates an Operation record with result = queued, and enqueues the work. The trigger call returns immediately.
2. The operation moves to result = running. The platform prepares the export in parts and collects them in a temporary staging table in the enrichment destination, named _qly_export_staging_<operation id>. Once every part has arrived, it writes the export output from the staging table in a single step and removes the staging table.

3. When the write completes, the operation transitions to one of:

   Result	Meaning
   success	The export completed. An export that matches no containers also ends in success, and its message says no containers matched.
   failure	The export did not complete, for example because it exceeded a size limit.
   aborted	The export was stopped before it completed.

The operation is visible on the source datastore's Activity tab from the moment it is queued. The page auto-refreshes as the result changes.

While the export runs, its progress bar shows an estimated percentage of the whole export (staging, preparation, joining source records for merged exports, and writing). The estimate is based on comparable exports that completed earlier, so the first exports of a given kind give only a rough figure. Once comparable exports have completed, the status line also shows the time remaining; if the run outlasts that estimate, it reads Taking longer than estimated instead. The bar reaches 100% only when the export succeeds. If the dataplane does not report export progress, the bar animates without a percentage and is labeled Progress unavailable.

Export size limits¶

An export is never refused because of its size when you request it: Qualytics prepares it in parts, so an export of every container in a datastore runs like any other. The limits below are safeguards, checked while the platform prepares the data, regardless of the asset type:

Source records are not counted toward the record count: a merged export writes one row per source record, so it can write more rows than the count it is checked against.

An export that exceeds one of these stops and finishes with result = failure, and the operation message names the limit that was exceeded. Because the export output is written only after every part has been staged, an export that fails or is aborted before that final write leaves the output from an earlier successful run unchanged. A failure during the final write itself can leave the output incomplete on some destinations; run the export again to replace it.

If an export keeps exceeding these limits, cover fewer containers per run: switch the container selection from All to Specific or Tag and split the export into several smaller runs. Copy each completed batch to another location before starting the next run: each run replaces the same output, even when you select different containers. The limits are set at the deployment level; if a legitimate export keeps exceeding them, ask your administrator (self-hosted) or Qualytics support (managed deployment) about adjusting them.

Scheduling¶

An Export Operation can be scheduled to run on a recurring cadence. Schedules support:

• Hourly / Daily / Weekly / Monthly / Custom Cron frequencies
• Any IANA timezone (e.g. America/New_York, Europe/Paris, Asia/Tokyo). The default is UTC.
• Automatic Daylight Saving Time handling: a 9:00 AM job in America/New_York runs at 9:00 AM local time year-round.

Deactivating a schedule keeps its cron expression. Reactivating it later resumes the same schedule without re-entering anything.

See Schedule Export for the modal walk-through.

Re-running a completed export¶

Any user with Editor permission on the source datastore can re-run a previously completed Export Operation. The re-run uses the original operation's parameters (asset type, container selection, include_masked and merge_source_records flags) and produces a fresh operation. The new operation overwrites the existing export output on completion.

Re-runs are allowed only after the original operation has finished: attempting to re-run an in-progress operation produces an error.