Reverse-ETL fails when bad rows ship. Kestra chains Airbyte, dbt build, dbt test, and the Hightouch sync. A failing test halts the chain before any row touches Salesforce, and row counts post to the approval channel before production fires.
Reverse-ETL has one failure mode that matters: pushing bad data to the CRM. Kestra wraps Hightouch with the steps that make activation safe. It runs Airbyte ingest with retries that don't cascade, builds and tests dbt models as a hard gate before any sync (see dbt Core or dbt Cloud), fans out to Salesforce, HubSpot, and Iterable in parallel with per-destination isolation, and pauses for human approval with row counts surfaced.
Hightouch solves the destination wiring and field mappings. Kestra solves the steps that have to run around the sync to make activation safe.
Hightouch's scheduler does not know whether the model it is about to read passed its tests. If a dbt test regresses overnight, the next sync activates bad rows to Salesforce or HubSpot. Kestra runs dbt test as a separate task between build and sync. A failure halts the chain, pages the on-call, and the Hightouch sync never fires. The classic reverse-ETL anti-pattern of shipping silently broken data disappears.
Hightouch's run history stops at the destination boundary. It has no record of the Airbyte connection that produced the warehouse data or the dbt build that shaped the activation mart. Kestra runs Airbyte, dbt, and Hightouch as steps in one flow. Step retries do not cascade: a dbt retry never re-runs Airbyte, a Hightouch retry never re-runs dbt, and run IDs from each step flow forward for traceability.
Promoting a sync from staging to production with no human review burns trust the first time a definition change ships ten thousand wrong rows. Kestra runs the staging sync first, posts the row counts to a notification channel (Slack, Microsoft Teams, or any webhook target), and pauses for a named reviewer. Only after explicit approval in the Kestra UI does the production sync fire. Reviewer identity and timestamp are stored in execution history.
Hightouch's built-in scheduler fires on a cron interval. If dbt runs long or a Fivetran sync slips, the next tick activates stale rows. Kestra triggers the Hightouch sync the moment the upstream task confirms success, whether that's a dbt build, a webhook from Fivetran, a Snowflake task event, or any HTTP signal. The cron padding that builds on stale data goes away.
One activation mart powers Salesforce, HubSpot, Iterable, and Braze through separate Hightouch syncs. With one scheduler, a Salesforce API outage takes down the whole batch. With Kestra, allowFailure on each task isolates the failure: HubSpot keeps shipping, and the right owner gets paged for the right destination.
Hightouch's UI is built for sync configuration. It does not give marketing a form to fire a one-off Iterable resync after a campaign launch, or ops a button to backfill HubSpot after a data correction. Kestra Apps wraps any flow in a typed form. Non-engineers fire the sync they need, and every trigger lands in execution history with the user's identity.
Patterns reverse-ETL teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.
Airbyte syncs, then dbt builds the activation marts on BigQuery (or Snowflake, Postgres, Redshift), then Hightouch fires. Slack confirms with the Hightouch run ID. Step retries stay local: a dbt failure never re-runs Airbyte.
A dbt retry never re-runs the Airbyte ingest, and a Hightouch retry never re-runs dbt.
Airbyte job ID, dbt results, and the Hightouch run ID land in one execution view.
Swap the dbt image for dbt-snowflake, dbt-postgres, or dbt-redshift.
Data quality checks gate the activation. Kestra runs dbt build, then dbt test as a separate task. A test failure halts the chain and pages PagerDuty so the on-call can fix the regression before any row touches HubSpot or Salesforce. On pass, Hightouch fires and Slack confirms.
Hightouch never fires when dbt test fails. Bad rows do not reach the CRM.
Quality regressions page the rotation, not just log to Slack.
Swap dbt test for any quality framework. The gate is task-level, not tool-specific.
One activation mart, many destinations. Kestra fans the dbt output to multiple Hightouch syncs in parallel: Salesforce for sales ops, HubSpot for marketing, Iterable for lifecycle messaging. Failures are isolated per destination, and the failing sync's owner is paged directly.
Parallel for speed, or sequential with allowFailure when downstream depends on upstream.
Salesforce failure pages sales ops, HubSpot failure pages marketing. Not the whole data team.
Hightouch outputs the run ID and metrics per sync. Kestra surfaces them in one execution view.
Kestra runs the staging Hightouch sync, posts row counts to Microsoft Teams as an Adaptive Card, then pauses. The reviewer reads the added, removed, and changed counts in the Pause description and resumes in the Kestra UI. Only then does the production sync fire. Identity and timestamp logged automatically.
Reviewers are paged the moment staging finishes. The Pause is not a silent wait.
Templated from outputs.run_staging.runId and the Hightouch run metrics.
Identity and approval moment stored in execution history automatically.
Same flow drives both environments. Staging and production sync IDs are typed inputs.
Schema changes force a full reload, but Salesforce caps the data loader at 5,000 records per call and HubSpot at 100 per batch. Kestra fans the syncs in waves with delays between, sets fullResynchronization to true from a typed input, and surfaces per-destination metrics without tripping limits.
Typed flow input flips the Sync task between incremental and full reload with no code change.
Built-in Sleep task delays the next wave so the destination API does not throttle.
Non-engineers trigger a full resync through a form without touching YAML.
Kestra has been a keystone to design complex execution flows while enhancing our Infrastructure as Code best practices. It now empowers our ingestion with Airbyte, transformation with dbt, and our Hightouch reverse-ETL jobs seamlessly.
| Capability | | | | GitHub Actions |
|---|---|---|---|---|
| Trigger Hightouch on upstream completion | Native event triggers | Event polling, Python code required | Sensor-based polling | Cron or Git events only |
| dbt test as a gate before Hightouch sync | Native task ordering | Python flow logic required | Operator chain | Step ordering, no native dbt operator |
| Approval gate before customer-facing sync | Native pause + resume | Available in Prefect 2.x+ | Custom sensor workaround | Environment approvals (deploy only) |
| Per-destination failure isolation in fan-out | allowFailure + per-task error handlers | Task-level retry | Per-task retry, custom error routing | Limited |
| Row-level Hightouch metrics in execution view | Surfaced as task metrics | Custom logging required | Custom logging required | Logs only |
| Self-service triggers for marketing or ops | Kestra Apps | No native form layer | No | No |
| Declarative YAML, IaC-friendly (Terraform) | Pure YAML + Terraform provider | Python first, YAML deployments | Python DAGs | YAML, limited to repo events |
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
Run the canonical reverse-ETL chain in one flow, gate activation on dbt tests, and audit every row push. Open source, self-hosted, event-driven.
