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.

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.