Record Anomalies¶

A Record anomaly flags one row of a table or file that failed one or more checks. It is the most specific evidence a Scan can give: the exact row, the exact field, and the value that broke the rule. The simplest Record anomaly is a row with no value in a field that must always be filled in.

This page explains when a failure becomes a Record anomaly, what one contains, and how to read it. For failures that concern many rows or the dataset as a whole, see Shape Anomalies.

When a Failure Becomes a Record Anomaly¶

A Scan reports a failure as a Record anomaly when all of these are true:

The rule evaluates each row on its own. Rules such as Not Null, Min Value, or Matches Pattern decide row by row whether the data passes. Rules that look at the dataset as a whole, such as Unique or Volumetric, always produce Shape anomalies instead.
The check's coverage is 100%. Every row must pass. With a lower coverage, the check tolerates some failing rows and reports a failure as one Shape anomaly for the dataset.
The check failed few enough rows. When a check fails more rows than the Scan's Maximum Record Anomalies per Check (10 by default), all of that check's failures are reported as one Shape anomaly instead of one Record anomaly per row. See Maximum Record Anomalies per Check.

See Rule Types for every rule type that can produce Record anomalies.

One Anomaly per Row¶

By default, a Scan creates one Record anomaly per failing row, not one per failed check. When the same row fails several checks, those checks are grouped into a single anomaly:

The Failed Checks section lists every check the row failed, each with its own message.
The anomaly's Impact is the highest among its failed checks, so the most serious rule the row breaks decides how it ranks.
The anomaly starts with the Default Anomaly Assignee of every failed check that has one. See Anomaly Assignees.

One Anomaly per Check¶

The One anomaly per check scan default changes this grouping. It is set in Platform Defaults and can be overridden per datastore and per table or file:

One anomaly per check	Anomalies for a row that fails 3 checks	Failed checks on each anomaly
Off (default)	1	All 3 checks
On	3	1 check each

Leave it off when your team remediates row by row, so each anomaly shows every issue found on a row. Turn it on when your team remediates check by check, so each anomaly covers one check. With the setting on, each anomaly has its own status, Impact, assignees, and notifications, and its own copy of the row in the enrichment datastore. See One anomaly per check for the full behavior.

A check that was rolled up into a Shape anomaly, or that has a coverage below 100%, is not part of these groups. The same row can then appear in a Record anomaly for its other checks and among the source records of a Shape anomaly.

What a Record Anomaly Shows¶

Part	What it shows
Anomalous Records	Always 1: the row the anomaly is about.
Failed Checks	Each check the row failed, with a message that names the field and the value, such as `salary has the value 30000, which is under the minimum of 40000`.
Source Records	The row itself, with every field. The cell that failed is highlighted, so you can see the problem without reading the whole row. The row is stored only when the source datastore has an enrichment datastore. See Source Records.
Description	A summary of the failure built from the failed checks. See Anomaly Description.

A check can replace the standard message with the value of another column on the same row, such as a column that already explains the row in business terms. That option, Custom Anomaly Description, changes Record anomaly messages only.

How a Later Scan Recognizes It¶

Every Record anomaly gets a fingerprint built from the checks it lists as failed and every value in the row. If a later Scan finds the same row failing the same check, with every value unchanged, it produces the same fingerprint, so duplicate handling can archive the new anomaly as Duplicate or reopen the earlier one. Change any value in the row and the fingerprint changes too, and the Scan reports a new anomaly.

Rule Types¶

These rule types evaluate each row, so they produce Record anomalies. All of them except Metric also produce a Shape anomaly when the check's coverage is below 100% or when it fails more rows than the limit.

Rule Type	Record Anomalies	Shape Anomalies
After Date Time
Any Not Null
Before Date Time
Between
Between Times
Contains Credit Card
Contains Email
Contains Social Security Number
Contains Url
Equal To
Equal To Field
Exists In
Expected Values
Greater Than
Greater Than Field
Is Address
Is Credit Card
Is Type
Less Than
Less Than Field
Matches Pattern
Max Length
Max Value
Metric
Min Length
Min Value
Not Empty
Not Exists In
Not Future
Not Negative
Not Null
Positive
Predicted By
Satisfies Expression

Examples¶

The Sample Data tables below follow the Source Records view: one row per record, with only the failing cell highlighted.

A Value Below a MinimumOne Row, Two Failed ChecksThe Same Row in the Next Scan

The situation: Your employees table feeds payroll, and every salary must be at least 40,000. A Min Value check on salary, with a minimum of 40000 and 100% coverage, guards that rule.

Sample Data

emp_id	name	department	salary
101	John Doe	Finance	52000
102	Bob Johnson	Support	30000
103	Jane Smith	Engineering	75000
104	Ana Lima	Support	28500

What gets flagged

Rows 102 and 104 are under the minimum. Each failing row becomes its own Record anomaly, so the Scan reports two anomalies, one per employee. Only the salary cell is highlighted: the other fields are part of the row, not of the failure.

Record Anomaly (emp_id 102)

salary has the value 30000, which is under the minimum of 40000

Record Anomaly (emp_id 104)

salary has the value 28500, which is under the minimum of 40000

The situation: Your orders table has two checks: a Not Null check on customer_id, because every order must belong to a customer, and a Positive check on amount, because an order cannot have a negative total.

Sample Data

order_id	customer_id	order_date	amount
5001	C-310	2026-10-01	129.90
5002	C-118	2026-10-01	54.00
5003	NULL	2026-10-02	-15
5004	C-207	2026-10-02	310.25

What gets flagged

Order 5003 fails both checks. Because both failures belong to the same row, the Scan reports one Record anomaly with two failed checks, not two anomalies. Both failing cells are highlighted in its source record, and its Impact is the higher of the two checks' levels. With One anomaly per check turned on for the orders table, the Scan reports two Record anomalies instead, one for each check.

Record Anomaly (order_id 5003)

customer_id has no value

amount has the value -15, which is not positive

The situation: The employees table from the first example is reloaded every night with the same data, and the Scan runs with Archive Duplicate Anomalies turned on. Yesterday's Record anomaly for emp_id 102 is still open.

Sample Data (the next night)

emp_id	name	department	salary
101	John Doe	Finance	52000
102	Bob Johnson	Support	30000
103	Jane Smith	Engineering	75000
104	Ana Lima	Support	41000

What gets flagged

Row 102 fails again with every value unchanged, so the new Record anomaly has the same fingerprint as the open one and is archived as Duplicate right away. The open list keeps only yesterday's anomaly. Row 104 now passes: its salary was corrected, so no new anomaly is created for it. If the nightly Scan is a Full Scan, which has Auto Resolve Anomalies on by default, yesterday's anomaly for row 104 is resolved by this Scan. See Auto-Resolve on Full Scans.

Record Anomaly (emp_id 102, archived as Duplicate)

salary has the value 30000, which is under the minimum of 40000

Record Anomalies¶

When a Failure Becomes a Record Anomaly¶

One Anomaly per Row¶

One Anomaly per Check¶

What a Record Anomaly Shows¶

How a Later Scan Recognizes It¶

Rule Types¶

Examples¶

See Also¶