Problem:

When the Fivetran connector detects a source side data type change for a column, it currently handles the change by:

1. Adding a new staging column with the new type,
2. Backfilling data via cast,
3. Renaming the original column to a deprecated name,
4. Renaming the staging column into the original column's name,
5. Dropping the deprecated (original) column.

If a Snowflake masking policy is attached to that original column, the policy binding is destroyed in step 5, because masking policies attach to a specific column object and are not carried over when a column is dropped/recreated. The result is that a previously protected column becomes silently unprotected with no notification, warning exposing potentially sensitive data to unauthorized roles until the customer manually discovers and remediates it.

Observed incident:

On our end, this occurred on ct_152_rejoyn_us_dynamodb where the connector changed the data type of VALUE column from TEXT to VARIANT via the add/copy/rename/drop sequence on 2026-07-30. The column had an active masking policy, after the migration, POLICY_REFERENCES showed zero policies on the column,  and it remained unprotected until we identified it via manual investigation on 2026-08-05



Requested behavior

1. Before performing a schema/type change that requires drop-and-recreate of a column, have the connector check whether the columnhas a masking policy, row access policy, or tag-based policy attached.
2. If a policy is detected, emit an alert/notification identifying the affected table/column and the policy that will be lost, before completing the drop.

Business impact

Sensitive/PII data can be exposed to unauthorized roles for an unbounded period without any signal from Fivetran, creating a compliance and security risk that is difficult to detect proactively.

1. Downstream joins break silently. Since the column's underlying type changed from TEXTto VARIANT as part of this same drop-and-recreate process,  any existing joins,  filters, or transformations against this column.This surfaces as intermittently wrong row counts or missing matches in downstream pipelines, with no error thrown and no upstream notification that the source schema changed. Combined with the masking-policy loss, a single unannounced type change causes both a security exposure and a silent data-quality/correctness issue across dependent pipelines.

Requested outcome A native alerting mechanism (or, longer term, an option to preserve or reapply masking policies across type driven column recreation) for schema changes that affect policy protected columns, so customers are notified proactively rather than discovering exposure and broken joins after the fact.