Integration Layer
The connections moving data between systems, and the rules governing direction, timing and conflict.
What to document
Direction of flow for each field
Trigger: real time, scheduled, or manual
Conflict rule: which side wins when both changed
Failure behaviour: what happens when the sync fails, and who finds out
Failure is usually silent
How to document yours
List every connection: source, destination, and what moves. Most organisations cannot produce this list, and producing it is most of the value.
For each field that moves, record the direction and which side wins on conflict. Bidirectional sync without a declared winner is the single most common cause of data that flips back and forth.
Record the timing: real time, scheduled, or manual. Reporting discrepancies are frequently timing rather than error.
Name an owner per connection. An integration with no owner is discovered when it breaks, usually by someone who cannot fix it.
Record what happens on failure. Silent failure is the default for most integrations and is why data drifts unnoticed for months.
Where it goes wrong
Bidirectional sync is far riskier than it appears: without a declared authoritative side, two systems overwrite each other indefinitely.
Integrations are built to solve one problem and then quietly depended on by three others, so their blast radius is larger than their documentation.
Field-level mapping drifts as either system changes, and nothing alerts you — the mapping simply stops matching reality.
Volume limits and API quotas produce partial syncs that look like data quality problems rather than infrastructure ones.
RELATED TERMS
Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
Data Orchestration
Coordinating how data moves and transforms across systems so a multi-tool stack behaves like a single one.
Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
Systems of Record
The set of systems that each hold authoritative data for part of the business, and the map of which owns what. The architectural decision underneath every reporting question.
Tech Stack
The set of systems a revenue team operates, and — more importantly — how they relate to each other.
COMMON QUESTIONS
- What is an integration layer?
- The set of connections moving data between systems, together with the rules governing direction, timing and conflict resolution. It is infrastructure rather than a tool — the same two systems can be connected in ways that produce reliable data or continuous drift.
- Should integrations be bidirectional?
- Rarely, and never without declaring which side is authoritative for each field. Bidirectional sync without a declared winner means two systems overwrite each other indefinitely, producing values that flip between states and reporting nobody can reconcile. One-way sync from a system of record is safer.
- Why do integrations break silently?
- Because failure handling is usually an afterthought. Most integrations log an error nobody monitors and continue, so a connection that stopped syncing three months ago is discovered when someone notices the data is wrong. Recording what happens on failure — and alerting someone — is the cheapest reliability improvement available.
- How do you document an integration layer?
- One row per connection: source, destination, fields moved, direction, conflict winner, timing, owner and failure behaviour. Most organisations have never written this down, and the act of writing it usually surfaces two or three connections nobody knew were still running.
FURTHER READING
Learn how to apply this: CRM Admin 101
Definitions are the vocabulary. The courses are where you learn to operate it, with the interactive audit tools.
See the course