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, enriched contacts into HubSpot, or customer segments into Klaviyo. 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; if the goal is visualization, see 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, Snowflake, Amazon Redshift, Databricks, or PostgreSQL. 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, 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. 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.
3. Connect the application destination following 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:
   • 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.
6. Optionally adjust the sync schedule on the Scheduling tab, check the Data Preview, name the flow, and click Create Flow.

Configuration recommendations

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).

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).
• 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 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).
• Data quality: The 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 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.
• 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.
• For generic errors (authorization, API limits, broken sources), see Troubleshooting.