Integrations: connecting new software to the systems you already run
No business tool works alone. A CRM without telephony and invoicing is a card index; a BI platform without access to the accounting database is a slide generator. Integration is where software projects either become useful or quietly become double data entry.
There are three ways systems talk. A native connector, built and maintained by the vendor, is the cheapest and most reliable - if it exists for your exact version. An open API with webhooks means a developer can build the exchange you need, and someone must maintain it as both sides release updates. An integration platform or middleware sits in the middle, routing data between several systems, and pays off when you have four or more of them.
Before you accept the word "integrates" on a feature page, ask three questions: which objects and fields are synchronised, in which direction, and how often; what happens to a record that fails validation on the other side; and who fixes the connector when the accounting system upgrades. Answers in writing are worth more than a screenshot of a settings screen.
Decide the source of truth
Most integration pain is not technical. It is two systems that both believe they own the client record. Fix that on paper first: the CRM owns contacts and deals, the accounting system owns invoices and payments, the warehouse owns stock. One owner per entity, one direction of sync for each field, and a rule for conflicts. Everything after that is configuration.
Sequence matters too. Launch the core product first, let the team work in it for two weeks, then connect the second system. Simultaneous rollouts make it impossible to tell whether a problem comes from the software, the data or the exchange - and they double the training load on the same week.
We map the integration landscape during discovery, so the shortlist only contains products that can actually connect to what you run today. Where a connector exists, we configure it; where it does not, we scope the work with the vendor and put the estimate in the same quote - no discovering in month two that the exchange is a separate project.
Map the data before you map the systems
Most integration pain is data pain wearing a technical costume. Before anyone writes a connector, build a mapping table: which entities exist in both systems, which fields correspond, which side owns each field, and what the shared identifier is. Then decide the deduplication rule, because two systems that create customers independently will produce two versions of the same company within a week.
One source of truth per field. Not per system. The ERP may own price and stock while the CRM owns contacts and pipeline stage, and both can write to the same customer record as long as the ownership is explicit and documented.
Failure is the normal state - design for it
Networks drop, APIs rate-limit, a required field appears in a release note nobody read. The question is not whether a sync fails but what happens in the twenty minutes afterwards.
- 01Retries with idempotency. Every message carries a key so a repeat delivery cannot create a duplicate invoice or a second shipment.
- 02A dead-letter queue with an owner. Failed records land somewhere visible, and a named person gets an alert - not a log file nobody opens.
- 03A reconciliation report. A daily count and value comparison between systems. It catches silent divergence long before finance does.
Who owns the integration in year two
A one-off script written during rollout by a contractor is the most expensive integration pattern there is. Name an owner, keep the mapping table and the credentials documented, hold a test environment where an upgrade can be rehearsed, and version the interface so a vendor release does not become an outage. Where possible, prefer the vendor's supported connector over a clever custom one: it comes with someone else's regression testing.
Instrument the boundary. Sync latency, error rate and queue depth on one small dashboard. Integration problems are cheap while they are still invisible to customers.