---
title: "Data Activation (Reverse ETL)"
slug: "data-activation-reverse-etl"
updated: 2026-07-12T16:16:18Z
published: 2026-07-12T16:16:18Z
canonical: "docs.dataddo.com/data-activation-reverse-etl"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataddo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Activation (Reverse ETL)

At the end of this guide, you will have a ***data flow*** that reads modeled data from your data warehouse or database and writes it into a business application - for example, lead scores into [Salesforce](/docs/salesforce-as-a-destination), enriched contacts into [HubSpot](/docs/hubspot-destination), or customer segments into [Klaviyo](/docs/klaviyo-destination). Choose this pattern when the consumers of your data are **people working inside operational tools**, not analysts. If you are moving data *into* a warehouse instead, see [Batch Ingestion to Data Warehouses](/docs/batch-ingestion-to-data-warehouses-etl-elt); if the goal is visualization, see [Data to Dashboards](/docs/data-to-dashboards).

## Architecture

Reverse ETL (also called **data activation**) inverts the usual pipeline direction: the **warehouse or database is the source**, and the **application is the destination**.

1. **Source**: Connect your storage as a ***data source*** - for example [Google BigQuery](/docs/google-bigquery-source), [Snowflake](/docs/snowflake-as-a-source), [Amazon Redshift](/docs/amazon-redshift-as-a-source), [Databricks](/docs/databricks-as-a-source), or [PostgreSQL](/docs/postgresql-as-a-source). The table or query you extract typically contains **already-modeled data**: propensity scores, segments, lifetime value, enriched contact attributes.
2. **Flow**: A batch ***data flow*** picks up the most recent extraction on schedule and applies **field mapping** to translate your columns into the destination application's fields.
3. **Destination**: The application connector writes records through the application's API using the write mode you select.

Because extraction and writing run on schedules, every sync carries the **most recent extracted state** of your model into the application, keeping operational records aligned with your analytics layer. There is no SmartCache in this pattern - data moves from your storage, through the flow, directly to the application's API.

### Why activate data

As described in the [Applications overview](/docs/applications), sending enriched data back into business applications:

- Breaks down data silos
- Improves data accuracy
- Shares proprietary company data across departments
- Eliminates the need for separate dashboards

Typical activation scenarios include syncing **customer behavior data to a CRM** for targeted communications (marketing), keeping a **customer's value and risk profile** in front of sales representatives (sales), and routing **feature-request signals** back to the CRM for prioritization (product management).

## Decision guide

For application destinations the write-strategy question reduces to: does this sync **create** records, **update** existing ones, or both? Use **insert** when you push net-new records (e.g. new leads), **update** (or **update ignore**) when the records already exist in the application and you only refresh attributes (e.g. a score field on existing contacts), and **upsert** when a run can contain both - upsert matches records by a **unique identifier** and updates matches while inserting the rest. Unlike storages and warehouses, which typically offer insert, insert ignore, truncate insert, upsert, and delete, each application exposes an **app-specific subset** - often insert plus update/update ignore/upsert variants that map to the application API's operations on existing objects. The flow setup UI always shows the valid subset for the selected destination.

## Setup walkthrough

1. **Create the source** from your warehouse or database following [How to Create a Data Source](/docs/creating-a-data-source). Extract exactly the table, view, or query result you want to activate - one row per target record.
2. **Add the Dataddo Hash** (recommended) in the source's **Advanced Settings** if you plan to upsert; it gives you a ready-made unique key. See [Metadata Inclusion](/docs/metadata-inclusion).
3. **Connect the application destination** following [How to Connect a Data Destination](/docs/how-to-connect-a-data-destination). On the Destinations page, application connectors are on the **Applications** tab.
4. **Create the flow** following the application-specific steps in [How to Create a Data Flow](/docs/how-to-create-a-data-flow#create-a-data-flow-application-as-a-destination):
  - Select your **write mode**.
  - Choose the **unique identifier** used to map data to the application.
  - Define **mapping columns** based on the write mode. For **upsert**, include at least one mapping column containing your unique ID (the **Dataddo Hash** is recommended). For **insert**, the flow will ask for the application's **specific pre-defined fields** required to insert the rest of the data.
5. **Map the fields.** Field mapping aligns your source columns with the destination application's fields and data types (text, dates, numbers), preserving context - a phone number lands in a phone field, not an address field. See [Field Mapping](/docs/applications#field-mapping).
6. Optionally adjust the **sync schedule** on the Scheduling tab, check the **Data Preview**, name the flow, and click **Create Flow**.

## Configuration recommendations

| Scenario | Write mode | Unique identifier | Notes |
| --- | --- | --- | --- |
| Refresh scores/LTV on existing CRM records | Update (or upsert) | Application record ID or your business key | Map only the fields you refresh |
| Sync segments where new and existing contacts mix | Upsert | Dataddo Hash or business key | Include the unique ID in mapping columns |
| Push net-new records (e.g. leads, offline conversions to [Google Ads](/docs/google-ads-destination)) | Insert | Not required | Fill the application's required pre-defined fields |

Schedule the source extraction and flow so each run picks up a fresh model output; for most activation scenarios a **daily or hourly** cadence is sufficient (see [Batch Extraction](/docs/extraction)).

## Operations

- **API limits**: Application APIs restrict call counts and payload sizes. Dataddo handles third-party API limits during extraction with pagination and dynamic request sizing (see [Batch Size Limitations](/docs/extraction#batch-size-limitations)).
- **Backfilling**: Reverse ETL flows normally carry only current state, but if you need to re-push a historical range from a date-partitioned source, see [Data Backfilling to Storages](/docs/data-backfilling-to-storages) for how manual loads work.
- **Monitoring**: Watch source health on the Sources page; broken sources stop syncing (see [Troubleshooting: How to Fix a Broken Source](/docs/troubleshooting#how-to-fix-a-broken-source)).
- **Data quality**: The [Data Quality Firewall](/docs/data-quality-firewall) applies to **data storage destinations only**, not application destinations. To keep bad rows out of your CRM, enforce quality rules on the upstream pipeline that loads your warehouse, so the tables you activate are already validated - or use the [Data Quality Watcher](/docs/data-quality-watcher) to alert on anomalies.

## Troubleshooting

- **Records duplicated in the application**: usually an insert-mode sync running over overlapping data. Switch to **upsert** with a stable unique identifier (Dataddo Hash or a business key). See [Handling Data Duplicates](/docs/data-storages#troubleshooting).
- **Rows rejected on write**: check that every mapped column matches the destination field's data type, and that all pre-defined fields required for insertion are mapped, as described in [How to Create a Data Flow](/docs/how-to-create-a-data-flow#create-a-data-flow-application-as-a-destination).
- For generic errors (authorization, API limits, broken sources), see [Troubleshooting](/docs/troubleshooting).