Fivetran integration for ecommerce reporting

Fivetran runs on configurable schedules (hourly, daily, or event-driven for supported systems). You set freshness thresholds and wire Fivetran's API into your observability platform to alert when an extract falls behind; the integration team responds to alerts and investigates connector failures.

Fivetran will report the failure in its dashboard and log an error. If you have not set up alerting, the failure may go unnoticed for hours. Observability integration ensures your on-call team is paged immediately and can check credentials, network access or ERP downtime.

Fivetran detects the new field and lands it in your warehouse table automatically. Your dbt transformations may ignore it or fail if they reference hardcoded column lists; this is caught in dbt testing. You then decide whether to include the new field in your modelled tables or ignore it.

Yes, Fivetran's reverse-ETL feature allows you to sync warehouse tables back to your ecommerce or CRM system. You must explicitly define which warehouse columns map to which target fields, test the sync thoroughly, and set up rollback procedures in case of errors.

Fivetran extracts whatever your source systems expose; it does not filter or mask data. You must configure row-level and column-level access control in your warehouse (Snowflake, BigQuery, Redshift) to restrict who can see sensitive fields, and optionally use data masking or PII detection tools.

Your analytics engineering team owns the dbt layer. They monitor schema notifications from Fivetran, update transformations in Git, test changes in a dev environment, and deploy fixes to production. Without a named owner, fixes may be delayed and dashboards may break.

You build dbt tests and SQL queries that compare Fivetran row counts, sums and deduplication logic against source system counts. These tests should run on every dbt deployment and alert if counts diverge by more than a threshold, signalling incremental load failures or duplicate rows.

You should test reverse-ETL in a staging environment first and have a rollback plan. If wrong data goes to production, your ecommerce team may need to revert changes manually or restore from a backup. This is why reverse-ETL mappings must be reviewed and tested with business stakeholders before going live.

You build reconciliation queries that track expected vs. actual row counts, look for duplicate keys, and compare checksums of key fields between source and warehouse. These checks should run after each extract; mismatches alert your team to investigate Fivetran logs and rerun the connector if needed.

Both are common. Direct warehouse access gives analysts flexibility but can lead to inconsistent definitions and duplicated SQL. A semantic layer (Looker, Power BI, dbt Semantic Layer) enforces one version of truth, applies access control, and makes dashboards faster and more maintainable.

Fivetran bills per connector and data volume. You should audit which systems actually feed dashboards and which can be disabled, configure incremental loads to reduce volume, and exclude unnecessary columns. Review costs quarterly as your estate changes.

Fivetran supports full refreshes and historical replays for most connectors. You can run a full refresh of your old ERP or ecommerce system in parallel with your new system, land both into the warehouse, and compare data before cutting over. This requires careful table naming and reconciliation logic.

You use dbt's built-in lineage documentation, Fivetran's API lineage, and optionally a data catalogue tool (Collibra, Alation) to show the full path from source system to dashboard. dbt generates this automatically when you run dbt docs; you then publish it to a team wiki or BI tool.