In Fivetran, what do the Allow All, Allow Columns and Block All schema change settings do?

## The problem the setting exists for Sources change shape. A SaaS application ships a feature and adds a field; an application team runs a migration and adds a table. An ingestion pipeline has to decide, without a human in the loop at 3am, whether that new structure should appear in the warehouse. Every managed EL tool has to answer this; Fivetran answers it with a per-connector **schema change handling** policy with three settings. ## The three settings **Allow All.** The permissive end. Newly appearing tables are added to the sync, newly appearing columns in synced tables are added, and Fivetran issues the destination DDL to create them. You are guaranteed never to be missing a field because nobody noticed it appeared. **Allow Columns.** The middle position, and the usual default choice. The *table* list is curated — you decide which objects are replicated — but within those tables, new columns flow through automatically. This matches how most teams actually think: which entities matter is a deliberate decision, which attributes exist on them is the source's business. **Block All.** The restrictive end. Nothing new syncs. A new table or column is detected and left disabled until someone explicitly enables it. The warehouse schema only ever changes because a human decided it should. Whichever you pick, the setting governs *additions*. It does not make a connector immune to a genuinely breaking source change — a column being dropped or retyped at the source is a different event and needs its own handling and alerting. ## Why permissive hurts - **Cost.** New tables that arrive automatically are new rows being replicated, and under a per-changed-row consumption model that is a bill you did not approve. A source that adds a high-churn audit or event table can move your monthly consumption noticeably. - **Governance and privacy.** A source team adding a `ssn`, `date_of_birth` or free-text `notes` column gets it copied into the warehouse automatically, into a system with a different access model than the source. For regulated data this is precisely the failure mode compliance teams worry about — the data crossed a boundary with no review. - **Noise.** Analysts open a schema and find dozens of tables nobody has modelled, with no way to tell which are load-bearing. ## Why restrictive hurts - **Silent staleness.** The most common real-world failure with Block All is not an error — it is nothing happening. The source added `discount_amount` a month ago, the connector dutifully ignored it, and your revenue model has quietly been wrong. Nobody gets paged for a column that is *absent*. - **Toil.** Every source change becomes a ticket. In an org with many sources, that queue becomes the bottleneck it was meant to prevent. ## The setting is only half the answer The mature position is that the policy must be paired with **visibility**. Fivetran surfaces schema-change activity and can notify on it, and connectors typically expose their own metadata about what changed and when. Whatever the setting, someone should be able to answer "what changed in this source last week" without opening a support ticket. Concretely: - Route schema-change notifications to the team that owns the downstream models, not to a mailbox nobody reads. - Treat a new column as a *review* item even if it auto-synced: does it need masking, does it belong in a model, is it PII. - Keep downstream models defensive: select explicit column lists rather than `SELECT *`, so a new column arriving cannot silently change a model's output shape, and a disappeared column fails loudly instead of nulling. ## Choosing per connector, not globally The setting is per connector, and that is the right granularity. A well-governed internal application database whose team announces migrations can safely run Allow All. A third-party SaaS source you do not control, especially one carrying customer data, is a much better candidate for Allow Columns or Block All. A source under active regulatory scrutiny may justify Block All plus an explicit approval step, accepting the toil as the price of the control. ## What the interviewer is testing Not whether you can recite three option names — whether you understand that automatic schema propagation is a *policy* decision with a cost side and a privacy side, and that both extremes fail, just differently and on different timescales. The strongest answers name the silent-gap failure of the restrictive setting, because most candidates only think of the permissive one as risky. ## Version note Option names and the exact UI surface for schema handling have been revised more than once, and behaviour can differ by connector type. Reason from the three policy positions; confirm the current names and per-connector caveats in the vendor documentation.