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 instead of creating a new one. A Fingerprint column is written to the Enrichment Datastore to support this match. 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.
If the field is left blank in the scan form, the value is inherited from the datastore's Enrichment Settings.
Maximum Source Examples per Anomaly
This setting controls how many source records are stored in the Enrichment Datastore for each detected anomaly. The available limits are 10, 100, 1,000, or 10,000 records. 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.
If the field is left blank in the scan form, the value is inherited from the datastore's Enrichment Settings.
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 Datastore: source record values written during a Materialize operation are obfuscated for masked fields.
For more details, see Masked Fields in Source Records.