Before you build a CRM integration, answer these five questions

CRM integrations have a reputation for being simple: pull data from one system, push it into another. In practice they're where a surprising number of automation projects go sideways, because the hard part was never the API call, it was the decisions nobody made explicitly before the build started.

The questions that actually matter

• Which system wins on conflict? If a lead is updated in both places before a sync runs, one side has to lose, and that has to be a decision, not an accident.
• What counts as a duplicate? Email match, phone match, fuzzy name match, each catches different duplicates and creates different false positives.
• Is the sync one-way or two-way? Two-way sync without a clear conflict rule is how records start flapping between two different 'correct' states.
• What happens to a record that fails validation on the receiving end? Dropped silently, queued for review, or does it block the whole batch?
• Who's the source of truth for each field? Different fields can have different owners; deciding this once avoids re-litigating it during every bug report.

Every one of these has a reasonable default, but the default has to be chosen on purpose. We've seen integrations rebuilt from scratch three months in because 'the CRM is always right' turned out to be false for exactly one field that mattered a lot: deal stage, which sales reps update manually and which a stale automated sync kept quietly overwriting.

Write the sync contract down

Before building, we write a one-page sync contract: which system owns which field, what the dedup key is, what happens on conflict, what happens on error. It takes an hour and it's the document everyone points to six months later when someone asks 'why did this record change.' Without it, that question doesn't have an answer, just a guess.

A CRM integration isn't a data pipe. It's a policy about which system is allowed to be wrong, made explicit before it happens by accident.