Expected Schema Best Practices

Guidelines for getting reliable signal from Expected Schema checks while keeping the noise (and the maintenance) low.

Declare the contract, not today's table

Copying the current structure into the check produces a rule that fires on the first legitimate change. Declare the fields your consumers actually bind to, and let the rest of the table evolve, with Allow other fields on.

Turn off Allow other fields only for closed interfaces

A delivered file or a published extract has a fixed layout, and an unexpected column is a real breach. A warehouse table that several teams extend does not: leaving the toggle off there turns every unrelated addition into your anomaly.

Pair it with Field Count for cheap early warning

Field Count is inexpensive and catches additions and removals immediately. Expected Schema is the precise one, catching renames and type changes. Running both gives you a fast signal and an exact diagnosis.

Update the declaration as part of shipping a schema change

When a column is legitimately added, removed, or retyped, the check has to move with it. Treating that edit as part of the change keeps the anomaly queue meaningful instead of permanently red.

Say in the description where the contract comes from

"Matches the layout agreed with the partner in the integration spec" tells the next reader whether an anomaly means the data is wrong or the spec moved. A bare field list does not.

Route the anomalies to the right people

A failure usually points at the system that produced the value, not at the warehouse. Set an Anomaly Assignee from the team that owns that producer, and tag the check so related checks are easy to find.

See Also