Field Count Anomaly Reporting
How the Field Count check reports a schema change: what the Shape Anomaly tells you, and why there is nothing to report per row.
Anomaly Messages
Field Count emits a Shape Anomaly only, one per failed evaluation. The anomaly reports that the container's field count does not match the expected number, so the message carries the observed count and the number the check was configured with.
There is no per-row variant: the violation belongs to the container, not to any row inside it. There is also no filter suffix, because the rule accepts no filter.
What the Numbers Mean
- Observed count: how many fields the scan found on the container.
- Expected count: the Number of Fields configured on the check.
Comparing the two tells you the direction of the drift: more fields than expected means something was added, fewer means something was dropped.
Source Records Behavior
Field Count does not evaluate rows, so the anomaly carries no source records. The evidence is the container's own field list, which you can review on the container's page.
Custom Anomaly Description
Custom Anomaly Description does not apply to this rule. The option replaces the message on Record Anomalies, and Field Count emits a Shape Anomaly only.
See Also
-
How It Works
The complete reference: definition, container scope, the expected count, how the shape is evaluated, and why coverage and filters do not apply.
-
Examples
Three production scenarios showing a stable schema, a dropped column, and an added column.
-
Best Practices
Guidelines for pairing with Expected Schema, keeping the count current, and avoiding false alarms.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.