Seven plays for pushing warehouse data into the tools the business actually works in, run in order, each naming the owner, the trigger, the steps and the exit criteria. It includes the field ownership map that decides which system wins a conflict, the null-handling rules per field, and the suppression path every destination needs before the first sync runs.
The trap most data teams walked into: pick the destination first, hunt for a table worth sending, sync the model that already sits behind a dashboard because it is built, then leave two-way writes on so the warehouse and the CRM overwrite each other for a month before a rep finally mentions that their notes keep disappearing.
What the teams whose first sync survives do: start from a decision someone makes badly on a schedule, build one purpose-made model with a declared grain and a stable key the destination already knows, then sign a field ownership map that names one system of record, one direction and one conflict rule per field before anyone opens a sync tool.
Not per table, not per integration. Every field the sync touches gets one system of record, one direction, one conflict rule in plain language, and one named human who adjudicates when the value looks wrong. The warehouse owns computed things: scores, usage, lifecycle stage. The CRM owns human things: the account owner, the stage a rep set. If a field cannot be assigned to one system, it is two fields.
A null can clear the destination field, leave the previous value, or skip the record. Three different behaviours, and the sync tool picks one for you unless you pick first. Silent clearing is what wipes a rep's notes, and that is the day trust goes. Decide per field, write it down beside the mapping, and route anything unmapped to a rejects table with a reason.
Suppression belongs upstream, not in the destination. A suppressed person should never appear in the payload, so a misconfigured campaign cannot reach them. Resolve conflicts to the most restrictive value: if any system says do not contact, that is the answer everywhere. Then document a suppression path for every destination, including the ones people forget, ads audiences and the in-app messaging tool.
Owned by the Head of Analytics, before any vendor call. Name the person, the decision, how often they make it, what they use today, and what they would do differently with the field in front of them. Any blank and it does not qualify. Write the outcome as a baseline number the business owner has read and agreed.
Analytics engineering builds one table, one grain, tested with a uniqueness assertion and an owner in the code owners file. Key it on something the destination already knows. Then the business owner and the data lead sign the field ownership map, one row per field, carrying the system of record, the direction, the conflict rule and a human owner.
Coerce types explicitly, map enums against the destination's live picklist pulled from its API, and declare per field what a null means. Keep the mapping in version control next to the model. Detect change on a hash of the mapped columns rather than updated_at, upsert on the stable key, and run the backfill off-hours through the bulk endpoint.
The data lead and the DPO, before the first sync reaches a marketing tool rather than after. Model consent with a source, a timestamp and a scope, filter suppression in the model so a suppressed person never enters the payload, and keep a per-record destination log. Then run one real deletion request end to end and record how long it took.
No, but argue for it. Bidirectional is a genuine requirement in a few places and a loop generator everywhere else. The test is whether you can state, per field, which side wins when both changed since the last run. If nobody in the room can answer that, the field is not ready for two-way writes.
Because mapping screens are not reviewed. A transformation in a vendor UI has no diff, no test and no owner, so it changes without anyone noticing until a rep queries a value. Do the boundary work in the model, keep the mapping in version control beside it, and a change goes through review like any other code.
No, and it is the most common shortcut. Dashboard models carry display formatting, get reshaped whenever a chart changes, and move their grain without warning. The sync then breaks because somebody edited a BI tool, which is a cause nobody finds quickly. Build a purpose-made model with a documented grain and a uniqueness test
It is one afternoon. The field ownership map is a table with five columns,
and the meeting that fills it in is the cheapest hour in the programme. The alternative is the CRM and the warehouse overwriting each other for a month before anyone notices, and by then the sales team has stopped trusting both
systems.
Two, if they are owned. Teams that promise eight ship four half-owned ones and spend the following quarter unpicking them. Plays one to three fill the first thirty days, mapping, mechanics and monitoring the next thirty, and consent, suppression and the re-measured baseline the last thirty.
Heads of analytics and data leads being asked to put warehouse data into Salesforce. It assumes you have a warehouse worth syncing from, a business team that wants fields in their own tool, and no written answer yet to which system wins when both sides changed since the last run.
Drop your details and we'll send Bad Data Costs $12.9m A Year. Reverse ETL Syncs It Into The CRM. straight to your inbox - no spam, unsubscribe anytime.
Book a 30-minute activation review (logiciel.io)
Download the playbook