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.

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) 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.

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. 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) 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.

Maximum Record Anomalies per Check¶

The Maximum Record Anomalies per Check setting caps the number of record-level anomalies emitted per check. Once that cap is reached, additional findings are merged into a single rolled-up shape anomaly 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.

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.

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. For each container the scan loads, every record it loaded is written to a new output named <enrichment_prefix>_source_records_audit_<container_id>_<operation_id>, 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.

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 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.

The outputs appear in the enrichment datastore with the Source Records Audit purpose. For the naming and contents, see Source records audit outputs.

Field Masking and Scanning¶

Scan operations run normally on masked fields. Masking does not affect anomaly detection or quality check execution. The platform evaluates all checks using the actual source data.

When scan results are displayed, masked field values are obfuscated in the following surfaces:

• 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.
• Enrichment Destination: source record values written during a Materialize operation are obfuscated for masked fields.
• Remediation outputs: values are written to the enrichment datastore unmasked. When a remediation 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.
• 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.