What is a CRM integration, really?

Two systems agreeing about a record. The connector is the easy half — most platforms have one. The half that decides whether it works is the mapping: which system owns which field, what happens when both change it, and what the integration does with a record it cannot match. An integration without those answers moves bad data faster.

How do you connect a CRM and marketing automation?

Through a shared identity and an agreed direction of travel. The marketing platform usually owns behaviour — opens, clicks, form submissions — and the CRM owns the commercial state of the relationship. Decide that before you connect them, and the sync is straightforward. Decide it afterwards and you get two systems overwriting each other nightly.

What does a CRM consultant actually do?

Mostly, decide which system wins. The build work is real and it is learnable. The expensive part is getting the people who disagree about a definition to commit to one, and then making the systems enforce it.

Will this work with the tools we already pay for?

Usually, and that is the starting assumption — a migration is a project on top of the project you actually have. Where a tool genuinely cannot do what you need we will say so plainly rather than build a workaround that someone has to maintain forever.

Services

← All 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.

The seams we are asked about most

GoHighLevel → Salesforce: Two systems that both believe they own the contact. The question is which one holds the commercial state of the relationship and which one holds the acquisition record, and the answer decides the sync direction rather than the other way round. What to sync, and what not to.
Stripe → CRM: The payment is the only place revenue is definitely true. Joining it back to the opportunity — and the opportunity back to the first click — is what turns a CRM forecast into something finance recognises. Revenue attribution models.
Ad platforms ↔ CRM: Both directions matter. Source in, so the CRM knows where a lead came from; conversions back out, so the ad platform optimises against revenue instead of form fills. Why it has to run both ways.
n8n → warehouse and BI: Where the joins actually happen once more than two systems are involved. The connector is rarely the hard part; the state that says which records have already been processed is. Data automation consulting.

Questions we get asked

What is a CRM integration, really?: Two systems agreeing about a record. The connector is the easy half — most platforms have one. The half that decides whether it works is the mapping: which system owns which field, what happens when both change it, and what the integration does with a record it cannot match. An integration without those answers moves bad data faster.
How do you connect a CRM and marketing automation?: Through a shared identity and an agreed direction of travel. The marketing platform usually owns behaviour — opens, clicks, form submissions — and the CRM owns the commercial state of the relationship. Decide that before you connect them, and the sync is straightforward. Decide it afterwards and you get two systems overwriting each other nightly.
What does a CRM consultant actually do?: Mostly, decide which system wins. The build work is real and it is learnable. The expensive part is getting the people who disagree about a definition to commit to one, and then making the systems enforce it.
Will this work with the tools we already pay for?: Usually, and that is the starting assumption — a migration is a project on top of the project you actually have. Where a tool genuinely cannot do what you need we will say so plainly rather than build a workaround that someone has to maintain forever.

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.

Engagements are scoped to an outcome and priced as a fixed scope or a retainer, not by the hour. If the work is small enough to bill hourly, it is not work we should be taking.

Discuss a project LinkedIn

hello@core-x.solutions

Start with whichever is true

Taking on new work.