Integration, and When It Is a Trap
An integration removes a manual step and adds a dependency. Both are real, and the second is systematically underweighted because it is invisible until it fails. For a related reference point, Monitask has a guide to how Microsoft Teams tracks activity, which is useful when comparing whether a dedicated tool is warranted.
No affiliate links on this site, and nothing here is ranked.
The four kinds
Built-in. The vendor supports the connection directly. Most reliable, least flexible, and the one that survives updates.
Via a connector service. A third product sits between two others. Works, costs a subscription of its own, and introduces a second company that can change or fail.
Export and import. A file out, a file in, done manually or on a schedule. Ugly, robust, and free — and adequate for anything that does not need to be immediate.
And nothing. Somebody retypes it. Which is correct more often than the industry suggests, particularly at low volumes.
The question that decides it
How many times a week does this copying happen, and how long does it take?
Ten items a week at thirty seconds each is five minutes. An integration to save five minutes a week is a dependency bought for nothing, and it will cost more than five minutes the first time it breaks.
Two hundred items a week is a different answer, and so is anything where the copying introduces errors that cost real time to find.
Count before connecting. The number is usually smaller than the impression.
What an integration costs
It breaks. Not often, and without warning, and usually after one side updated something.
It fails quietly. The worst version: it stops syncing and nothing announces it, so the two systems diverge for a fortnight before anybody notices.
It constrains upgrades. A connection that works on your current plans may not survive a change to either.
And it is a switching cost. Every integration is something to rebuild if you move either tool, which quietly raises the price of leaving both.
When it is genuinely right
High volume, where the manual alternative is hours rather than minutes.
Where errors are expensive. Retyping invoice figures is error-prone and the errors cost more than the integration.
Where it must be immediate — something that has to happen before somebody acts on it.
And where it replaces a person's judgement with a rule that is genuinely deterministic, which is a narrow case and a good one.
The check to build in
Anything that syncs should be checked periodically, because it will not tell you when it stops.
A monthly look at both sides — do the totals agree, is the most recent item present in both — catches a silent failure before it becomes a fortnight of divergence.
Two minutes, and it is the difference between an integration that works and one that appeared to.
The trap version
Buying a tool for its integrations rather than for the job it does.
"It connects to everything" is a feature list, not a fit. The job is what to evaluate, and a tool that does the job poorly and connects widely is worse than one that does it well in isolation.
And an integration marketplace with hundreds of entries tells you about the vendor's ecosystem, not about whether the three connections you would actually use work well.
Test those three during the trial. The rest are decoration.
Direction matters
One-way and two-way integrations are different products with the same name.
One-way is simpler and safer. Data flows from the system of record into somewhere it is displayed or used, and conflicts cannot arise.
Two-way sync creates the possibility of a conflict — the same record changed in both places — and every two-way integration has a rule for resolving it. Find out what the rule is, because "last write wins" quietly discards somebody's work.
Where one-way is sufficient, choose it. Most requirements described as sync are actually one-way needs with a preference attached.
Building your own
Scripts and automation platforms make this accessible and the accessibility is the risk.
A connection somebody built in an afternoon is a connection nobody documented, that runs on somebody's account, and that will break when they change a password.
It is the same single-person problem as any other configuration and it is worse because it is invisible — nothing in either tool shows that a script is keeping them in step.
Where you build one, write down what it does and where it runs, on the same page as everything else. Five minutes, once.
What to do when it breaks
Stop syncing before fixing.
A broken integration reconnected without checking will happily propagate a fortnight of divergence in whichever direction it favours, and undoing that is considerably worse than the original failure.
Establish which side is right first, fix the data, then reconnect.
And treat a repeated failure as a decision point. An integration that breaks quarterly is a manual process with extra steps, and the honest response is usually to stop using it.
The integration you should always have
One exception to everything above: getting data out.
A scheduled export into your own storage is technically an integration and it has none of the drawbacks — nothing depends on it working, and its failure costs nothing in the moment.
It is the export habit made automatic, and where a tool supports it, switching it on is ten minutes and permanently useful. A separate outside reference is Ars Technica.
The short version
- An integration removes a manual step and adds a dependency, and the dependency is invisible until it fails
- Four kinds: built-in, via a connector service, export and import, or somebody retypes it — the last is right more often than suggested
- Count the copying first: an integration to save five minutes a week is a dependency bought for nothing
- The worst failure is silent — syncing stops, nothing announces it, and the systems diverge for weeks
- Check both sides monthly: do the totals agree, is the latest item in both
- Do not buy a tool for its integrations; test the three you would use and treat the marketplace as decoration