Unique Anomaly Reporting
How the Unique check reports duplicates: the anomaly message it produces, what the counts mean, how duplicate groups appear in Source Records, and why per-row reporting does not apply.
Anomaly Messages
When the Unique check fires, it produces a single Shape Anomaly describing the dataset-level violation. The Unique check does not produce Record Anomalies: uniqueness is a property of the dataset as a whole (a duplicate group), not of any individual row's value, so the platform reports the violation at the shape level only.
Single-field check:
Composite-key check:
The template wording uses "field" (singular) even when multiple fields are checked; the joined list inside the quotes is what distinguishes single-field from composite-key checks at a glance.
When a filter is set, the message ends with [filter: <expression>].
What the Numbers Mean
- X.XXX%: the fraction of filtered rows that participate in any duplicate group. If 2 rows out of 4 are part of duplicates, this reads
50.000%. - N: the total number of rows the check evaluated (after the filter, if any).
- K: the number of rows that participate in any duplicate group, counted in full (not "extras only"). For 2 rows sharing the same tuple, K = 2, not 1.
Because K is the full count (and not just the extras), the anomaly's row count matches 1:1 against the rows you would find by running the equivalent SQL WHERE (a, b) IN (duplicate combinations) query.
Source Records Behavior
Because the violation belongs to a duplicate group rather than to one row, Source Records show every row in each duplicate group, not just the extra copies. That makes the group readable end to end: you can see which record should survive and which are the duplicates to remove.
Custom Anomaly Description
Custom Anomaly Description does not apply to this rule. The option replaces the message on Record Anomalies, and Unique emits a Shape Anomaly only: the violation belongs to a duplicate group, not to a single row.
See Also
-
How It Works
The complete reference: definition, field scope, single-field and composite semantics, NULL handling, filter behavior, and coverage.
-
Examples
Production scenarios with sample data, duplicate groups, and the resulting anomaly messages.
-
Best Practices
Guidelines for NULL handling, composite keys, scoping, and pairing rules.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.