When building on Fivetran-synced tables, always filter WHERE _fivetran_deleted = FALSE (or _fivetran_active = TRUE in history mode) in every downstream query, or deleted rows will pollute aggregates. For GDPR-style hard deletes, add a post-load transformation step. Agents that count rows or join Fivetran tables without the deleted filter will produce silently wrong numbers.

Context: Fivetran docs (deleted source data): Fivetran never hard-deletes in the destination. Deleted source rows are soft-deleted via a _fivetran_deleted BOOLEAN column set to TRUE. To actually remove data, run DELETE or DROP in the destination yourself, or write a post-load transformation that deletes where _fivetran_deleted = TRUE. In history mode there is no _fivetran_deleted column at all; deleted rows are marked with _fivetran_active = FALSE and every version is kept.