Syncs

Operator sets sync mode to 'upsert' on a Salesforce destination. They expect rows removed from the warehouse to disappear from Salesforce.

upsert mode inserts new rows and updates existing rows by match key — it does NOT delete destination rows that vanished from the Model. To propagate deletes, use mirror mode (or upsert + delete sync, per destination support). Document the chosen mode in the sync description so operators know the li…

A real-time personalization use case is scheduled with a 1-hour interval; downstream Braze sends emails with stale state.

Pick schedule per use case: cron/interval for batch attributes, triggered (dbt Cloud / API trigger) for chained workflows, streaming for low-latency personalization (where destination supports it). Document the freshness requirement and pick the cheapest schedule that meets it.

A sync run ends with status=warning: 4,998,500 rows synced, 1,500 rejected. Operator's monitor only alerts on status=failed and the partial failure is ignored.

Alert on both failed AND warning statuses with a rejected-row threshold (e.g., >0.1% or >100 rows). Treat warning as a real failure mode requiring inspection — partial data loss is harder to spot than total failure. Per docs, rejected-rows are surfaced in the run UI for triage.