fivetran schema change dropped a column, downstream models failed

TL;DR

Fivetran faithfully replicates the source schema, so a dropped source column disappears from the warehouse and every model selecting it fails. Find the drop in the connector's schema change history, fix the downstream models to stop referencing the column, and decide whether the drop was intentional. Then add a schema-change alert so the next drop is news, not an outage.

fivetran schema change dropped a column, downstream models failed

Use this when

• Downstream models fail on a column that used to exist.
• The connector's schema history shows a column drop.
• Dashboards break with missing-field errors after a sync.

Not for this skill when

• You dropped the column on purpose. Update the models as part of the change.
• The column exists but has nulls. That is a data problem, not a schema problem.

Steps

1. Check the connector's schema change log for the drop: which column, which table, which sync. Note the change. Verify: the drop is confirmed and dated
2. List every downstream model, dashboard, and export referencing the column. Note the full blast radius. Verify: nothing that references it is missed
3. Decide with the source owner whether the drop was intentional. Note the verdict. Verify: intent is established
4. Update downstream to stop selecting the dropped column or to source the data elsewhere. Note all models compile. Verify: downstream is repaired
5. Enable schema-change notifications on the connector. Note the next change alerts before it breaks models. Verify: the next drop is visible

Variant phrasings

fivetran column dropped downstream failed

The symptom phrasing.

fivetran schema change alert

The prevention-shaped search.

Compatibility: All Fivetran connectors. Schema change history and notifications are dashboard features available for every connector.

Why it happens

Fivetran's job is to mirror the source, not to protect your models from the source. When the source drops a column, the mirror drops it too, and the breakage surfaces in dbt or BI, far from the cause. The schema change log is the bridge between those two places, but nobody reads it until something breaks. Column drops are rarely announced by source teams because to them it is cleanup; to you it is an outage.

Edge cases / pitfalls

• Select-star models silently lose the column instead of failing, which is worse: dashboards go wrong quietly. Explicit column lists fail loudly.
• A column that is dropped and re-added with a different type breaks models twice. Treat re-adds as new columns.
• Blocking schema changes in Fivetran pauses the sync instead of applying the drop. Choose block or apply deliberately per connector.
• Historical data for the dropped column remains in old partitions or snapshots. Decide the retention story for it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_elbxUIkVbJGNSnORHXa0DA