Reverse ETL, and the field ownership problem nobody scopes for

A churn score in Snowflake is a fact. The same score on the account record, in front of the rep who owns it, is a decision. What reverse ETL is for, what breaks after the sync works, and when not to bother.

The name is backwards, which does not help

ETL moves data into the warehouse. Reverse ETL moves it back out, into the tools people work in: Salesforce, HubSpot, the support desk, the billing system. The name describes the direction of travel rather than the point, which is why it gets dismissed as plumbing.

The point is that a number nobody sees changes nothing. A churn score sitting in Snowflake is an interesting fact. The same score on the account record, in front of the rep who owns that account, is a decision.

Why this became a category

The warehouse won. Customer data, product usage, billing history and support history now land in one place, modelled and mostly trusted. That was the hard part and most organisations have done it.

What did not follow is the last mile. The people who act on customers work in the CRM and the help desk, and those systems know almost nothing the warehouse knows. So the analysis happens in one place and the work happens in another, with a person copying between them or, more often, nobody bothering.

Gartner's 2026 survey of more than 1,200 data leaders found 72% now treat warehouse-native data activation as a critical capability, against 38% in 2022. That is a fast shift for an infrastructure category, and it reflects teams discovering that the warehouse project did not change behaviour on its own.

What actually breaks

The sync itself is the easy part. Every tool in this space does it. The problems show up in the weeks after.

Two systems both think they own the field. Your warehouse computes an account tier. A Salesforce workflow also sets it. Whichever writes last wins, and the two disagree quietly for months. This has to be settled per field before anything syncs, and settling it is a business conversation rather than a technical one.

API limits decide your architecture. Salesforce and HubSpot both throttle. Syncing 400,000 records every hour is not a configuration choice, it is a design constraint that dictates batch size, frequency, and which fields are worth syncing at all. Teams that skip this discover it in production.

Bad data now has legs. A wrong metric in a dashboard misleads whoever opens it. The same metric pushed into the CRM triggers workflows, routes leads, and fires emails to customers. Reverse ETL raises the cost of a data quality problem, which is why it belongs after a certified metric layer rather than before one.

Nobody can explain where the number came from. A rep sees a health score of 34 and asks why. If the answer lives in a dbt model nobody outside the data team reads, the score gets ignored within a month. Field-level lineage back to a definition is what keeps it trusted.

When it is worth doing

The test is whether a decision is already being made badly with worse information. If reps are guessing which accounts to call, that is a decision waiting for data. If nobody is making the decision at all, syncing a score does not create the process, and the field just sits there.

Most enterprise deployments run 3 to 10 destinations, usually starting with the CRM and marketing automation before widening. Starting narrow is the right instinct: one field, one destination, one team that asked for it, and a way to tell in a month whether they used it.

When it is not

If your metrics are not certified, fix that first. Reverse ETL on contested definitions distributes the argument rather than settling it.

If the destination team did not ask for the field, adding it changes nothing. The most common failure here is a data team shipping fifteen enriched fields nobody requested, then concluding the tooling was the problem.

What it costs to scope properly

The tooling is the smaller line. A first implementation covering one or two destinations with the ownership rules written down is typically a 4 to 6 week engagement, most of which is deciding who owns each field and what happens on conflict. Ongoing cost tracks record volume and sync frequency rather than seats.

Teams that treat it as a connector configuration finish in a week and spend the next quarter reconciling fields that fight each other.

Frequently asked questions

What is reverse ETL?

Moving modelled data out of the warehouse and into the operational tools people work in, such as the CRM, marketing automation, or the support desk. Standard ETL fills the warehouse; reverse ETL pushes the results back so a score or segment appears on the record a person is looking at rather than in a dashboard they would have to go and open.

How is it different from an integration or a sync?

An integration usually moves raw records between two applications. Reverse ETL moves the output of a model, a score, a segment, a lifetime value, which means the warehouse stays the place the logic lives. That matters because the definition then has one home instead of being reimplemented in each tool.

Do we need reverse ETL, or just better dashboards?

Dashboards serve people who go looking for a number. Reverse ETL serves people who will not, which is most frontline staff. If the decision happens inside the CRM, putting the number in the CRM is the only version that changes anything.

What breaks most often?

Field ownership. The warehouse and a native workflow both write the same field, the later write wins, and the two quietly disagree. Settling ownership per field before the first sync prevents almost all of it, and that is a business decision rather than a technical one.

When should we not do this?

When the metrics are not certified yet, because pushing contested definitions into operational tools spreads the disagreement instead of resolving it. Also when the receiving team has not asked for the field, since a number nobody requested gets ignored regardless of how it arrived.