Connecting a CRM to a finance system.

The most common integration in business, and the one most often done twice. The API is the straightforward part. What breaks it is everything that was never decided.

The hard part is not the connection

Both systems have interfaces, both are documented, and moving a record from one to the other is a modest piece of engineering. Projects do not fail there.

They fail on the decisions nobody made: which system owns the customer record, what happens when the same company exists twice, and what the integration should do when finance edits something sales also edits.

Decide ownership field by field

For every field that exists in both systems, one of them owns it and the other displays it. Written down, field by field, before anything is built.

Where two systems can both write the same value, you have not built an integration, you have built a race. The symptom appears weeks later as values that change back on their own, and it is miserable to diagnose after the fact.

Matching records is the real work

Company names do not match across systems. Limited, Ltd, and the trading name are three spellings of one customer, and neither system enforces which one gets typed.

This needs a deliberate matching rule, a shared identifier where one exists, and a decision about what happens to records that cannot be matched. The correct answer is that they are held and reported, never guessed at and never silently dropped.

Decide what a failure does

An interface that fails loudly is a minor operational annoyance. An interface that fails quietly is a data problem that surfaces at year end.

Every integration needs a defined behaviour for a failed record, an alert to a named person, and a way to replay what did not go through once the cause is fixed.

Sequencing that avoids the rebuild

Start one-directional. Move data the way it needs to flow most, prove it against real records, and run it alongside the manual process until both agree.

Add the second direction only once the first is trusted, and only where the ownership rules make it safe. Most integrations built in both directions at once get rebuilt.

Decide these before any code is written

Checklist

  • Which system owns each shared field
  • The rule for matching a company across both systems
  • What happens to a record that cannot be matched
  • Whether data flows one way or both, and why
  • Who is alerted on failure, and how a failed record is replayed

Questions we get asked.

Can a connector from the app store do this?

Sometimes, and it is worth trying first for a straightforward setup. Off-the-shelf connectors handle the common path and tend to stop at custom fields, matching rules, and useful error handling.

What if our systems have no API?

Scheduled file exchange and direct database access both work. The pattern changes and the reliability engineering grows, and the result is the same.

How long does it take?

A single well-scoped direction between two mainstream products is usually weeks rather than months. The variable is the state of the data, not the interface.

Start with the problem.

Describe what is slowing the operation down. We will come back with the approach, the scope, and what it costs.

Get in touch