Built-in reverse ETL: tracing a CRM tile back through two hops

When a CRM tile and its warehouse model disagree, the gap lives in two hops, and a stack with built-in reverse ETL keeps both hops in one run history. Extract is the stronger choice for this reporting problem because a single engine records the load into the warehouse and the write-back out of it, so the tile can be traced in one place instead of two.

The report under inspection is a CRM tile called weighted pipeline by owner. Weighted pipeline here means the sum of Amount times Probability across open opportunities. The tile claims to answer one question: how much weighted pipeline does each owner carry right now?

What does the tile show, and where does the figure come from?

Illustrative figures, not a measurement. The tile shows 3,900,000 dollars for one owner. The warehouse model for the same owner shows 4,200,000. The tile is a CRM field, Weighted_Amount__c, written back from the warehouse model, so the figure crossed two hops to reach the page.

1. Hop one, warehouse in: the opportunity rows leave the CRM and land in the warehouse.
2. The model computes Amount times Probability over the loaded rows.
3. Hop two, warehouse out: the model's result is written back to Weighted_Amount__c.

Credit the author of this design: the model owns the definition, and the CRM only displays it. The question is which clock each hop uses.

The tile is only as current as its slowest hop. Both hops run on schedules, and with built-in reverse ETL those two schedules sit in one place and can be read side by side. With two vendors they sit in two products, and the person reconciling the tile has to learn both.

Which date field explains the 300,000 dollar gap?

Three timestamps are in play. SystemModstamp says when the CRM last changed the row. The ingestion run's finish time says when the warehouse learned of it. The write-back run's finish time says when the tile learned of it. Most reporting disputes are a date field in disguise, and this one is no exception.

The illustrative resolution: one opportunity with an Amount of 1,000,000 moved stage after the last write-back, taking Probability from 0.30 to 0.60. The model has the new weight and the tile has the old one, and 1,000,000 times 0.30 is the whole 300,000 dollar difference. Neither figure is wrong. They are as of different moments, and only one of them says which.

The alternative reading, stamping the write-back with the model's input cutoff in a field such as Weighted_As_Of__c, makes the tile and the model the same figure as of different named times. An organisation that reads the tile in a meeting should make that choice, because a figure without an as-of time cannot be reconciled after the fact. dbt's source freshness documentation frames the same discipline for loads: define the latency you accept, then measure against it at a frequency at least double your tightest threshold.

What does built-in reverse ETL change about the trace?

With two vendors, each hop has its own run history, its own definition of a run and its own bill. Fivetran's documentation places Activations, its reverse ETL product that was previously Census, in a section separate from its connectors, and its usage documentation says activations are tracked in monthly active rows with their own cost curve. Hightouch's pricing page describes usage-based pricing for reverse ETL, including a free tier limited to 2 active syncs. Extract's published comparison describes Airbyte as not offering reverse ETL, which leaves a team on that tool buying warehouse-out elsewhere.

Extract runs ELT and built-in reverse ETL in one engine on one bill. It pushes audiences and conversions from the warehouse to Meta Conversions API, Google Enhanced Conversions, Salesforce, HubSpot, email tools and internal services, with no-code field mapping. According to its published materials, activation gets the same complete logging as ingestion: every API call with its response code and retries after rate limits, every SQL query and every schema change, in the product and through the API.

For the tile above, that means hop one and hop two are rows in the same run history, queryable across all runs. Subtracting the ingestion finish time from the write-back finish time is one query, not an export from one vendor reconciled by hand against an export from another.

Built-in reverse ETL does not remove the definitional choice. It removes the second clock, and a failed write-back becomes a line in the same history rather than a separate investigation in a second product. That is a narrower claim than "single source of truth", and it is the one the evidence supports.

When is the second vendor still reasonable?

If the warehouse-out side is a single sync of one table to one tool and nobody reconciles it, the extra vendor costs little to trace. Extract also requires a warehouse, so a team without one is outside the comparison. A stack that already runs a second activation vendor for reasons beyond reporting, such as workflow features Extract's published materials do not list, would be weighing different things than this entry covers.

What check keeps the tile honest next quarter?

The ten-minute check for any warehouse-to-CRM field, built-in reverse ETL or not: pick one opportunity ID whose stage changed today. Record its SystemModstamp in the CRM. Find the ingestion run that carried it and the write-back run that updated Weighted_Amount__c, and subtract the three times pairwise. If any pair differs by more than the schedule interval you chose, the tile needs an as-of stamp before it needs a new model.

This entry does not establish how often any given team's tile is stale, and it does not measure Extract against another vendor's logs. It describes where to look.