# Scan Settings

Source: https://userguide.qualytics.io/operations/scan/deep-dive/scan-settings/

This page is a conceptual reference for the settings exposed in the **Scan Settings** step of the scan form. For the step-by-step UI walkthrough, see [Scan Settings: Step 4 of 5](https://userguide.qualytics.io/operations/scan/how-tos/scan-settings/).

## Anomaly Options

Anomaly options govern how anomalies are handled across consecutive scans of the same containers. They affect lifecycle decisions only, never the detection logic itself.

### Archive Duplicate Anomalies

When enabled, anomalies generated by the current scan that exactly match anomalies from a previous scan (same check, same [fingerprint](https://userguide.qualytics.io/anomalies/deep-dive/triage/fingerprints/)) are automatically archived with status **Duplicate**. This prevents the same finding from appearing as a new open anomaly every time the scan runs. The archived anomaly stays linked to the original so analysts can trace the duplicate chain. Anomalies without a fingerprint are never archived this way: shape anomalies on a data asset with no incremental identifier or last-modified date, and every Freshness and Volumetric anomaly.

Use this option when you expect the same anomaly to recur across scans and you want to keep the open list focused on truly new findings.

### Reactivate Recurring Anomalies

When enabled, an anomaly produced by the current scan that matches an **archived** anomaly from a previous scan reactivates the original as **Active**, and the new detection is marked **Duplicate**. Anomalies archived as **Duplicate** are never reactivated. This option requires **Archive Duplicate Anomalies** to be turned on. The match uses the anomaly fingerprints Qualytics keeps, so it works without an enrichment destination. When one is configured, a **Fingerprint** column is also written to the [Enrichment Destination](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/tables/#_failed_checks-table). This is useful when the same underlying issue resurfaces after being resolved or archived, since it preserves the anomaly's existing history and tags.

### Auto Resolve Anomalies

When enabled, previously open anomalies ([Active or Acknowledged](https://userguide.qualytics.io/anomalies/deep-dive/triage/status/)) are automatically resolved at the end of a Full scan whose checks no longer detect the same issue. This option is hidden and does not apply to Incremental scans. It is enabled by default for Full scans. The resolving scan is attributed in each auto-resolved anomaly's history.

For the eligibility rules and full behavior, see [Auto-Resolve on Full Scans](https://userguide.qualytics.io/operations/scan/deep-dive/read-strategies/#auto-resolve-on-full-scans).

## Maximum Record Anomalies per Check

The Maximum Record Anomalies per Check setting caps the number of record-level anomalies emitted per check. When a check fails more records than the cap, all of that check's findings are merged into a single rolled-up [shape anomaly](https://userguide.qualytics.io/anomalies/deep-dive/concepts/shape-anomalies/#more-failing-rows-than-the-limit) that preserves the total violation count. The setting does not limit detection: every violation is still found, but results above the threshold are presented as one consolidated shape anomaly instead of individual record anomalies. Use a higher limit when you need each anomaly individually for downstream remediation; use a lower limit when you only need to know that a check failed at scale.

The default is **10**. The maximum is **1,000**: values above 1,000 are silently capped to 1,000.

The scan form comes already filled in with the source datastore's value, which is set from the platform's [Scan defaults](https://userguide.qualytics.io/settings/platform-defaults/how-tos/configure-scan-defaults/).

## One anomaly per check

**One anomaly per check** decides whether a record that fails several checks produces one record anomaly listing all of them (off, the default) or one record anomaly per failed check (on). It is not part of the scan form. The value comes from the scanned container, then its datastore, then the Platform Default, so every scan of a container splits anomalies the same way. Leave it off when your team remediates record by record, and turn it on when it remediates check by check. Maximum Record Anomalies per Check still applies per check when it is on. Shape anomalies are always one per failed check. See [One anomaly per check](https://userguide.qualytics.io/settings/platform-defaults/deep-dive/how-it-works/#one-anomaly-per-check).

## Maximum Source Examples per Anomaly

This setting controls how many **source records** are stored in the Enrichment Destination for each detected anomaly. The limit accepts any value from 1 to 1,000,000,000; the scan form offers preset chips for common values. Source records are the rows that caused the anomaly and are the only records that can be viewed or downloaded later from the anomaly details.

The limit must be set **before** the scan runs. Changing it afterward does not retroactively expand the captured records. If you need more records for an existing anomaly, raise the limit and re-run the scan.

The scan form comes already filled in with the source datastore's value, which is set from the platform's [Scan defaults](https://userguide.qualytics.io/settings/platform-defaults/how-tos/configure-scan-defaults/).

## Persist Source Records for Audit

When enabled, the scan writes a snapshot of the source data it read into the source datastore's [enrichment datastore](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/introduction/). For each container the scan loads, every record it loaded is written to a new output named `<enrichment_prefix>_<operation_id>_<container_id>_records_adt`, with the source container's own columns. Use it when an audit requires the source data exactly as it existed when the scan ran.

The option is off by default and is set per scan run, scheduled scan, or Flow scan action. It requires an enrichment datastore, like the [remediation strategy](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/how-it-works/#remediation-strategies).

What gets written is what the scan loaded, nothing more and nothing less:

- **Anomaly limits do not apply.** Maximum Source Examples per Anomaly, Maximum Record Anomalies per Check, and other anomaly limits do not cap the audit snapshot.
- **The read settings do apply, check filters do not.** An Incremental scan writes only the incremental slice, and the [Record Limit](https://userguide.qualytics.io/operations/scan/how-tos/read-settings/#record-limit-per-container) still bounds how many records are loaded. A check's own filter narrows what that check evaluates, not what is loaded, so the snapshot holds every loaded record, including rows no check looked at.
- **Containers that are not loaded get no snapshot.** A container with no checks that need to read its records is not loaded, so no audit output is written for it.
- **A failed write fails the container.** The snapshot is written while the container is scanned, one partition at a time. If a write fails, that container's scan fails and its snapshot is not reported as written. Run the scan again once the enrichment datastore accepts writes.
- **Restarts keep the option.** Restarting a scan that has the option on is refused if the source datastore no longer has an enrichment datastore. Run a new scan instead.

> **Warning: Storage grows with every scan**
>
> Each scan creates a new output per loaded container, and each output is a copy of the data read. Outputs accumulate and can be large. Qualytics does not remove them, so plan retention in the enrichment datastore itself.

The outputs appear in the enrichment datastore with the **Source Records Audit** purpose. For the naming and contents, see [Source records audit outputs](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/tables/#source-records-audit-tables).

## Field Masking and Scanning

Scan operations run normally on [masked fields](https://userguide.qualytics.io/fields/field-status/concepts/field-masking/). Masking does not affect anomaly detection or quality check execution. The platform evaluates all checks using the actual source data.

Masking applies differently to each place scan results appear. Qualytics obfuscates masked values when it displays them, but outputs written to the enrichment datastore may hold the original values:

- **Anomaly Source Records:** values are hidden by default; users with Editor permission can reveal them per anomaly.
- **Anomaly Descriptions:** check failure messages permanently show `<masked>` in place of actual values; the original value is not stored.
- **Materialize outputs:** source record values written during a [Materialize operation](https://userguide.qualytics.io/operations/materialize-operation/materialize-operation/#field-masking-and-materialize) are obfuscated for masked fields.
- **Source records output:** the anomaly source records a scan writes to the `<prefix>_source_records` output in the enrichment datastore are stored unmasked. Qualytics masks them when it displays them, as described under Anomaly Source Records, but anyone who queries the enrichment datastore directly sees the original values, so restrict direct access to it.
- **Remediation outputs:** values are written to the enrichment datastore unmasked. When a [remediation output](https://userguide.qualytics.io/source-datastore/enrichment-datastore/deep-dive/tables/#remediation-tables) is previewed in Qualytics, fields masked on the source container stay masked, and revealing them needs reveal permission on both the source container and the enrichment datastore.
- **Source Records Audit outputs:** values are written to the enrichment datastore unmasked. When the output is previewed in Qualytics, fields masked on the source container stay masked, and revealing them needs reveal permission on both the source container and the enrichment datastore. When an audit output is itself scanned with the option on, the new output keeps the original source's masks, and revealing needs permission at every step back to that source. Anyone who queries the enrichment datastore directly sees the actual values, so restrict access to it before turning the option on.

For more details, see [Masked Fields in Source Records](https://userguide.qualytics.io/anomalies/deep-dive/anomaly-details/source-record/#masked-fields).

*Last updated: November 4, 2026.*