Connecting your CRM to your product: the decision to make before the integration
The connection works in the demo. Three months later nobody knows which system is right about a record. A CRM integration is a data governance question dressed up as a technical project. The four ways to connect, and the table to write first.
The connection works in the demo. Three months later a salesperson edits a record in the CRM, someone edits the same one in the product, and nobody knows which of the two is right. That is where it breaks, not in the code.
Connecting a CRM to your product is almost never a technical problem. It is a data governance question dressed up as an integration project. Until that question is settled, every synchronisation tool only moves the confusion around faster.
This article gives the method we apply before every integration. It comes down to three decisions, and it avoids most of the expensive rework six months later.
02
The four ways to connect, and what they cost over time
They all work on day one. They age completely differently, and that is the only criterion that really matters.
01
The native connector
Your CRM already offers an integration with your tool. Almost no setup cost, no maintenance. In exchange you take their data model as it is: if your notion of a customer does not match theirs, you bend your product to fit their box. Always check whether this connector exists first.
02
The integration platform
A third-party tool linking the two with visual scenarios. Quick to set up, readable by a non-technical person, billed on usage. The trap comes with volume: the bill follows your growth, and business logic ends up living in a tool nobody backs up or tests.
03
Home-made webhooks
You listen to CRM events and react inside your product. Little code, an excellent cost-to-control ratio. Plan for failures from the start: a lost webhook is a lost event, and without a retry queue you will discover the gap weeks later.
04
A custom API integration
You write the synchronisation yourself, both ways if needed. The most expensive to build, the only one that fits your business exactly. Justified when CRM data drives a product feature, not just a sales dashboard.
03
The decision that governs everything: who is right
Before the tool, before the budget, answer this: for each shared piece of information, which system is right when the two disagree?
The answer is not global, it is field by field. Generally the product is right about what it observes and the CRM is right about what a human typed in. A subscription status comes from the product. A commercial contact name comes from the CRM. Mixing the two logics produces silent overwrites.
One example of a split, to adapt to your business
Data
Source of truth
Direction of sync
Subscription status
The product
Product to CRM
Usage and activity
The product
Product to CRM
Contact and details
The CRM
CRM to product
Sales cycle stage
The CRM
CRM to product
Legal entity and billing
The billing system
Billing to both
Notice that no row is two-way. That is not a coincidence: once the source of truth is set, the need to sync both ways almost always disappears. And that is good news, because two-way is the expensive part.
04
Why two-way sync costs five times more
One way, you propagate a change. Both ways, you have to arbitrate conflicts, and a conflict has no good automatic answer.
Concretely: two edits to the same field seconds apart, which one wins? The most recent? Then a correction made by a human gets overwritten by an automated update that arrived after it. The system does exactly what it was told, and the data is wrong.
When it genuinely is needed, it is handled with per-field timestamps and a written precedence rule. It is doable, but it has to be a deliberate choice rather than a box ticked because it was in the specification.
05
What breaks in production, and the demo never shows
Four things, and they all arrive after go-live.
The third is the most insidious. An integration propagates creations and updates, very rarely deletions, and nobody notices until someone asks why a customer who left a year ago is still receiving emails.
The fourth is not only technical. If someone asks for their data to be erased, your answer has to cover the CRM, the product, and everything copied between the two. An integration multiplies the places data exists, and therefore the places it will have to be deleted from.
06
Where to start, concretely
The method is four steps, and the first needs no developer.
01
Write the source-of-truth table
One row per shared piece of data, one column for the system that is right, one for the direction of sync. This table is made by two people, someone from sales and someone from product, in an hour. It is the highest-return deliverable of the whole integration.
02
Check the native connector
Before pricing anything, look at whether your CRM already does what you want. The answer is yes more often than people expect, and it saves you a line of code and its maintenance.
03
Start with one direction and one piece of data
Pick the information with the most commercial value, often product usage pushed into the CRM, and do only that. In two weeks you will know whether the connection holds, on a scope where failure costs nothing.
04
Add the rest one field at a time
Every addition is a chance to check the source-of-truth table. Integrations that degrade are the ones that connected everything at once, leaving nobody able to say afterwards which flow writes what.
Three questions that come up before connecting a CRM.
How long does a CRM integration take?
For one direction and a few fields, starting from a native connector or webhooks, expect a few days to two weeks. For a custom two-way sync with conflict handling, expect several weeks plus ongoing maintenance. The gap does not come from the difficulty of the code, it comes from the number of edge cases you agree to handle.
Should I use an integration platform or build custom?
Start with the platform if the logic is simple and the volume modest: it is faster and can be changed without a developer. Move to custom when the usage-based bill becomes significant, when the business logic outgrows what a visual scenario can express, or when CRM data drives a product feature rather than just a dashboard.
How do I avoid duplicates between the CRM and the product?
With a shared identifier, decided before the first sync. Email is the default choice, imperfect but workable; a technical identifier owned by your product, written into a dedicated CRM field, is far better. What does not work is matching records on names: duplicates will appear, and cleaning them up afterwards costs more than setting the identifier at the start.
07
One decision, then an integration
Connecting a CRM to your product is a short project when data governance has been settled first, and an endless one when it has not. The technology always follows, it never decides.
So start with the source-of-truth table, one hour with two people. Then check the native connector, then connect one piece of data in one direction. You will have an integration that holds, and a clear idea of what the next one will cost.
“An integration does not synchronise data. It applies a decision someone made, or forgot to make.”
