How to build reverse ETL from the warehouse

What matters here

• Claim the fields the warehouse owns, in writing, before you build. Sharing a field with a person is how trust in the record dies.
• Sync deltas against a checksum or a modified timestamp. Full syncs burn the API limit and hide the change that mattered.
• Handle the rate limit as a normal condition, not an error. Every destination will throttle you and losing a row to a 429 is silent.
• Write to a dedicated field, not a shared one. A computed value belongs somewhere labelled as computed.
• Report rows synced against rows attempted. Silent partial syncs are the default failure and nothing announces them.

Who this is for

You run data or analytics engineering. The warehouse has the best version of the truth and the people who need it work in tools that have never seen it.

How it works in practice

The sequence, from a model updating to a rep seeing the result.

1. 1

   The model produces a table shaped for the destination

   One row per record, with the destination id already resolved. Reverse ETL should not be doing joins.

2. 2

   Changed rows are detected against the last sync

   On a checksum of the synced columns, so an unrelated column changing does not trigger a write.

3. 3

   Field ownership is checked before writing

   Only fields the warehouse claims. Anything shared with a person is written to a separate computed field instead.

4. 4

   Writes are batched and rate-limited

   Backing off on a 429 rather than dropping the batch, because a lost row is silent.

5. 5

   Nothing overwrites a value a person entered

   Human-entered fields are never touched, and the warehouse value goes somewhere labelled as derived.

6. 6

   Row counts are reconciled after every run

   Attempted, succeeded, failed and skipped. A partial sync that reports success is the common failure.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up and claim the fields before writing anything

   This is a negotiation with whoever owns the destination.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Snowflake and Salesforce,
   or whatever we run in those seats.
   
   Before building, produce the field ownership claim: exactly which
   Salesforce fields the warehouse will write, on which objects, and
   confirmation that no human process writes them. Custom fields carrying
   warehouse output should be named as such, so a Health_Score__c is
   visibly not a field a rep is meant to edit.
   
   My rule: never share a field. If a rep edits it, the warehouse writes a
   separate field with a clear derived label instead. A computed value and a
   typed value in the same field is a fight neither side knows they are
   having, and the rep loses faith in the whole record.
   
   Show me any field on my list that a person can currently edit. Those are
   the ones to move.

2. 2

   Sync deltas, on a checksum

   Full pushes burn the limit and hide the change that mattered.

   Headless skills build-workflow

   Copy

   Use build-workflow. Build the model into a table shaped for the
   destination: one row per record, the Salesforce id already resolved, and
   only the columns being synced. Reverse ETL should not be doing joins.
   
   Compute a checksum over the synced columns per row. Compare against the
   last successful sync and write only the rows whose checksum changed.
   
   That matters more than it sounds. Without it, an unrelated column
   updating in the model triggers a write to every record, which burns the
   API limit and makes the change you cared about invisible in the noise.

3. 3

   Write carefully, and treat the rate limit as normal

   A row lost to a 429 disappears without a trace.

   Headless skills tray-patterns

   Copy

   Batch writes to the destination limit, and treat a rate limit response as
   a normal condition rather than a failure: back off, retry, resume from
   where you stopped.
   
   Never let a batch failure lose rows silently. Record which rows were
   attempted, which succeeded, which failed and why, and make the failed set
   retryable on its own.
   
   Handle these:
   
     A destination record that has been deleted since the last sync
     A destination record that was merged into another
     A picklist value the model produced that the destination will not
     accept, which should fail loudly instead of writing blank
     A field that has been made read-only since the claim was agreed

   The merged-record case is the one that silently writes to a dead id for months. Reconcile against the destination periodically rather than trusting the ids you cached.

4. 4

   Never overwrite a person

   The rule that decides whether anybody trusts the data.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then enforce human precedence.
   
   Before writing any field, check whether the current value was last
   modified by a person, not by an integration. If it was, do not
   overwrite it. Write to the derived field and flag the divergence.
   
   Report those divergences. A field the warehouse and a rep disagree about
   repeatedly is either a model that is wrong or a process that should not
   be manual, and both are worth knowing.
   
   Never delete a destination value because the model produced a null. An
   absent value in the model is usually a join that did not match, not a
   statement that the value is empty.

5. 5

   Reconcile every run

   A partial sync reporting success is the standard failure mode.

   Copy

   After each run report: rows in the model, rows changed, rows attempted,
   succeeded, failed and skipped for human precedence.
   
   Attempted should equal succeeded plus failed. If it does not, rows went
   missing and the run should fail rather than report success.
   
   Also alert on staleness: if a sync has not completed within its expected
   window, the destination is now showing values that look current and are
   not. Stamp the last successful sync on the record so a reader can tell.
   
   Then report freshness by object and the divergence count. Both are
   invisible unless somebody produces them.

6. 6

   Check it end to end, then hand the field claim over

   Because ownership is agreed between two teams, not decided by one.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run in dry-run mode for a week first, computing every
   write and performing none, then read the diff with the team that owns the
   destination.
   
   Then open the same workflow in Tray Build so analytics engineering and
   revenue operations can amend the field ownership claim together.

What it connects to

One source, several destinations, and the discipline to write narrowly.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides