fivetran sync failed error "schema changes blocked: new column requires approval"

Not specified by the original author.

TL;DR

Approve or route the schema change deliberately instead of retrying the sync: open the Fivetran schema changes tab, identify the new column, and either approve it in the connector schema settings or block it there so the sync can proceed. Fivetran pauses a sync when a new source column appears and the connector is set to block schema changes; retries without a schema decision fail identically every time.

fivetran sync failed error "schema changes blocked: new column requires approval"

Use this when

• The check or run fails with this symptom: the Fivetran sync fails with schema changes blocked and a new column requires approval.
• You are working on a Fivetran connector whose sync is paused on an unapproved source schema change and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A regulated destination where new columns must be reviewed before landing, where the pause is the control working as intended.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Open the connector status page and read the exact schema change alert naming the new column and its source table. Verify: the blocked change is identified by name
2. Check the destination table to confirm the column is not already present under a different name or type. Verify: a naming or type conflict is ruled out
3. In the connector schema tab, approve the new column, or block the column if it must not land, and save. Verify: the schema decision is recorded on the connector
4. Trigger the sync again and watch it pass the schema check stage. Verify: the sync completes and the new column appears or stays blocked as decided
5. Set the connector schema change handling to the policy the team actually wants, auto-propagate or block, so the next change follows it. Verify: the policy is explicit instead of inherited

Variant phrasings

fivetran schema changes blocked new column requires approval

The shorter phrasing focused on the named failure.

fivetran sync failed schema change blocked

The symptom phrasing a searcher tries next.

fivetran new column approval sync paused fix

The variant naming the failing stage or tool directly.

Compatibility: Fivetran connectors with schema change handling set to block, managed and self-hosted destinations

Why it happens

Source systems add columns without notice. When the connector policy is set to block, Fivetran stops the sync to protect the destination schema, and the sync cannot resume until a human or an API call records a decision for that exact change.

Edge cases / pitfalls

• Approving a column also lands its historical values on the next sync; warn downstream owners before approving a column with sensitive content.
• Repeated blocked changes usually mean the policy should be auto-propagate for that connector, not faster manual approvals.

Provenance

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

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

Thread query: fivetran sync failed error "schema changes blocked: new column requires approval"

TL;DR: Approve or route the schema change deliberately instead of retrying the sync: open the Fivetran schema changes tab, identify the new column, and either approve it in the connector schema settings or block it there so the sync can proceed. Fivetran pauses a sync when a new source column appears and the connector is set to block schema changes; retries without a schema decision fail identically every time.

Not specified by the original author.

TL;DR

Fivetran hashes columns you mark as blocked, and a schema change can bring a column under a blocking rule you set earlier, for example a renamed column that now matches a name based block, or a new column that inherits a table level setting. Check the connector schema settings for that table and column, work out which rule fired, and adjust the block or hash choice deliberately. Remember data already loaded hashed stays hashed; fixing the setting only changes future syncs until you resync the table.

fivetran column hashed after schema change, pii column blocked

Use this when

• A column that used to arrive in clear text now contains hash values after a sync.
• The change coincides with a source schema change or a connector schema edit.
• Downstream reports break because the column no longer joins or displays as expected.

Not for this skill when

• The column is hashed inside the source system itself before Fivetran reads it. Fivetran is faithfully copying it.
• The whole table is missing. That is a sync or selection problem, not column blocking.

Steps

1. Confirm the values are Fivetran hashes rather than source values by checking the column across recent and older rows and noting when the format changed. Note the sync where hashing began. Verify: the start point of hashing is pinned to a sync
2. Open the connector schema tab for that table and inspect the column handling: allowed, blocked, or hashed, and whether the setting is inherited from a table or connector level rule. Note the rule that applies. Verify: the governing setting is identified
3. Correlate with the schema change: a rename into a blocked name, a new column matched by a pattern your team set, or a source type change that reclassified the column. Note the trigger. Verify: the reason this column, this week, is explained
4. Set the handling you actually intend for this column, with the data owner agreeing in writing if the column is personal data, and save the schema change. Note the new setting. Verify: the intended handling is explicit and owned
5. Resync the table if historical clear values are required and permitted, then verify new and historical rows match the decision. Note the destination state after the resync. Verify: the table contents match the policy decision, not just the setting

Variant phrasings

fivetran column suddenly hashed blocking schema change

The sudden change phrasing.

fivetran hashed column restore values resync

The recovery shaped search.

Compatibility: Fivetran schema blocking and hashing controls, available per connector, table, and column depending on plan. Hashing is one way: Fivetran cannot unhash values it already wrote.

Why it happens

Hashing is Fivetran's middle path between loading personal data in the clear and dropping the column entirely, preserving joinability without exposing values. The surprise in this failure is that the rule set is declarative and name driven, so a source side rename, often done by an application team who have never heard of the connector settings, can pull a column under a rule written months earlier for a different column with a similar name. Nothing malfunctioned; two independent changes composed into an outcome nobody chose directly.

Edge cases / pitfalls

• Treat unhashing a personal data column as a privacy decision, not a pipeline tweak. Get the data owner decision recorded before changing the setting.
• A resync to restore clear values re-reads the whole table and counts toward usage. Price it before you click.
• Downstream models may have adapted to the hashed values, for example joining on the hash. Restoring clear values can break those joins.
• Name based blocking rules deserve a review whenever the source schema changes. Put it on the schema change checklist.

Provenance

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

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

Thread query: fivetran column hashed after schema change, pii column blocked

TL;DR: Fivetran hashes columns you mark as blocked, and a schema change can bring a column under a blocking rule you set earlier, for example a renamed column that now matches a name based block, or a new column that inherits a table level setting. Check the connector schema settings for that table and column, work out which rule fired, and adjust the block or hash choice deliberately. Remember data already loaded hashed stays hashed; fixing the setting only changes future syncs until you resync the table.

Not specified by the original author.

TL;DR

Fix this in Snowflake usage sync by acting on the exact message first: update the usage sync column mapping for the renamed Snowflake column, point the sync at the new column name, replay the usage loads missed since the schema change, and verify a named account usage matches a direct warehouse query. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.

Snowflake usage sync broke after warehouse schema change column mapping error

Use this when

• The operation in Snowflake usage sync fails with this exact message or symptom: Snowflake usage sync broke after warehouse schema change column mapping error.
• The same failure repeats on retry with unchanged inputs.
• Health scoring, alerting or routing is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Snowflake usage sync, and copy the full message plus the account, measure or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: update the usage sync column mapping for the renamed Snowflake column, point the sync at the new column name, replay the usage loads missed since the schema change, and verify a named account usage matches a direct warehouse query. Verify: the smallest failing scope now completes, or the named account, measure or job behaves as the fix predicts.
3. Check the neighbouring accounts, measures or jobs that share the same config, schema or source, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Snowflake usage sync on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, scores or status against the source in Snowflake usage sync so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Sync mappings reference columns by name, and a warehouse rename breaks the mapping silently for the renamed field while every other field keeps flowing.

Variant phrasings

Snowflake usage sync broke after warehouse schema change column mapping error

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - Snowflake usage sync broke after warehouse schema change column mapping error

The how-to phrasing for the same failure in Snowflake usage sync. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Snowflake usage sync troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the sample scope but the full rerun still fails, a second account or record with the same fault is present; widen the scope in stages until the next failing item is found.
• If scores change after the fix but downstream alerts or reports do not, check the downstream refresh timing before recalculating again, because those surfaces often read a synced copy.
• If the source information itself is missing for the affected accounts, record that as a source gap rather than scoring the accounts as zero.

Compatibility: Snowflake usage sync at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: Snowflake usage sync broke after warehouse schema change column mapping error

TL;DR: Fix this in Snowflake usage sync by acting on the exact message first: update the usage sync column mapping for the renamed Snowflake column, point the sync at the new column name, replay the usage loads missed since the schema change, and verify a named account usage matches a direct warehouse query. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.