Services

CRM integration services

Connecting two systems is a weekend. Keeping them agreeing about the same customer, for years, through renamed fields and expired tokens and someone adding a picklist value on a Tuesday — that is the actual job.

The integration is not the hard part

Every platform has an API and every automation tool has a connector. Getting a record to move from one system to another is close to solved, and it is what most integration projects scope for.

The hard part is agreement. Two systems now hold the same customer, and sooner or later they will disagree about their name, their owner, their stage or whether they still exist. An integration that has not decided in advance how to settle that argument will settle it arbitrarily, and you will find out from a report that is wrong in a way nobody can explain.

Everything below is about deciding the arguments before they happen.

Three shapes, and what each costs you

Point-to-point

Use when: Two systems, one direction, a stable field list.

Cheap to build. Every new system multiplies the connections — five systems is ten integrations to maintain.

Hub and spoke

Use when: The CRM is genuinely the system of record and everything else reports into it.

Simple mental model. Fails when the CRM is not actually the authority on a field — billing usually is not.

Warehouse as the join

Use when: Several systems each hold part of the customer and you need to report across them.

More moving parts, but the only pattern where the join logic lives somewhere you can test and version.

Most businesses start point-to-point because the first integration is always two systems. The question worth asking early is which one you will be running at five systems, because that is where the maintenance cost stops being linear.

Five questions to answer before building

01What is the identity key?: Email is not it. People change jobs, share inboxes and type addresses wrongly. You need a deterministic key first — a billing ID, a domain plus company name, an external ID written back on creation — and fuzzy matching only as the second pass, with a documented rule for which record survives.
02Which system wins each field?: Not each record — each field. Billing owns payment status. The CRM owns owner and stage. Marketing automation owns consent. Write this down as a table before building anything, because the alternative is two systems overwriting each other on a loop.
03One direction or two?: Two-way sync doubles the failure modes and creates the possibility of an update ping-ponging between systems. Default to one-way per field, in the direction of the owning system. Bidirectional only where a human genuinely edits the same field in both places.
04What happens when it fails at 3am?: Not whether — when. A token expires, a rate limit trips, a field gets renamed by someone in another team. The integration needs a dead-letter queue, a retry with backoff, and an alert that names the record and the reason. Silent failure is the expensive kind.
05Is it idempotent?: If the same message arrives twice — and it will, because retries exist — does it create a second record? An upsert keyed on a stable external ID is the difference between a retry being harmless and a retry being a duplicate.

What actually breaks

None of these are exotic. All of them are things that will happen to a running integration, and each one has a design decision that prevents it.

API rate limits: Salesforce, HubSpot and most billing platforms cap calls per window. A backfill that ignores this gets throttled mid-run and leaves half the records updated — which is worse than none.
Field-level permissions: The integration user often cannot see the field you are syncing. It fails silently, returns null, and overwrites a real value with an empty one.
Picklist drift: Someone adds a stage in one system. The sync writes a value the other system rejects, and every record after it in the batch fails too.
Time zones and DST: Two systems storing local time, one of them without an offset, and a reconciliation that is quietly an hour wrong twice a year.
Deletes: Almost no integration handles them. A record deleted in the source lives forever in the destination, and your counts diverge by a little more each month.

A worked example

A subscription business with an outbound sales team had CRM records in Salesforce, call activity in Aircall, marketing source data in GoHighLevel and payment history in Chargebee. Nobody could answer what actually happened with this customer without opening four tabs and guessing.

The work was identity resolution before anything else: lead, call, opportunity and payment signals resolved to a single customer identity, deduplicated, then combined into one view in PostgreSQL. Only once the identity held did the reporting layer go on top.

Four systems became one view, with 100% of calls matched to CRM records — including, for the first time, visibility of the leads nobody had ever contacted. Full case study.

The same pattern at larger scale: nine sources conformed to one model across three brands and three CRMs, with brand carried as a column rather than as three separate reports that could disagree.

Where this usually starts

An integration built on top of a CRM full of duplicates propagates the duplicates. It is nearly always worth doing data quality first, or at minimum establishing the identity key before the first sync runs.

If you are moving between platforms rather than connecting them, that is a migration — a different job with a cutover, and one where the integration questions above still all apply.

Platform specifics: Salesforce, HubSpot, Zoho.

Tell us which systems disagree, and about what

That sentence is usually enough for us to say whether this is an afternoon, a fortnight, or a data quality problem in disguise.

Discuss a project

More on core services

All services →

Or start with the revenue operations overview that the rest of these hang off.

Have a messy system?

That is usually where we can help.

Tell us what is not working, what is still manual, or what you cannot currently see clearly. If it is not something we should take on, we will tell you that too.

Discuss a project

hello@core-x.solutions

Start with whichever is true

Taking on new work.