CRM Sync: Only the Second Test Counts

Why does the sync report success while duplicates pile up?

A sync can run without a single error and still produce wrong results. The green check confirms that two systems are reachable. It says nothing about whether a company gets matched on the second touch instead of created again. That is exactly where duplicates come from, and they only become visible weeks later, inside a live campaign.

The sequence is the same in almost every project. The team connects the enrichment tool to the CRM, connects the CRM to the sending tool, clicks test, gets three green lines and reports the integration as done. What was actually checked is reachability: the address resolves, the credentials work, the other side answers. That is a connection check, not a run with real data.

Our position: a sync counts as tested only once we have read back what the destination system actually holds. A saved configuration is an intention. A returned ID is a result. We build these chains in pipeline generation work regularly, and that distinction is the single most common reason a campaign surfaces problems in week two rather than week zero.

The damage is expensive because it is quiet. No tool raises an error when it creates a company for the second time. To the creating system that is a valid operation. It only surfaces when two sequences run at the same person, or when an existing customer receives a cold outreach email.

What has to be settled before anything gets built?

In most projects nobody can say which system is allowed to create a company. So two systems create, and both consider themselves responsible. Sales carries the consequence: duplicate records, unclear ownership, and time spent on cleanup instead of conversations. Ownership is decided up front, not reconstructed afterwards.

Before the first click, draw the path station by station. Where the data comes from, which system accepts it, where it lands. Every station carries one named responsibility. Who searches? Who creates? Who updates? Who writes the result back? As long as one of those four questions is open, nothing gets built.

We use three separate working surfaces rather than one wide table. The first carries the organisation, its identity, its matching, conditional creation, and the ID the destination returns. The second carries the person, the link to the organisation, and the same matching logic. The third carries the handover itself, meaning the approved person, the destination action and the release state.

Our position: a fourth surface exists only when it owns a step of its own. A surface that merely repeats what the others already hold makes the build wider and the defect harder to find. The same applies to country and role variants. A variant that only changes a field value is not a separate test. A variant that changes routing, permissions or matching is.

In practice that usually means Clay supplies the enriched organisation and person data, HubSpot is the destination where companies and contacts live, and Lemlist sits at the end as the sending tool. The tools are interchangeable. The four questions are not.

Deep Dive Guide · 17 pages · free

From signal to sales pipeline

Whether your market carries volume, which three to five signals count and where the chain would break. Plus the checks before the first send.

Explore guide →

Create or look up: which write path applies per object?

Many builds keep two write paths live at once, because nobody dared switch one off. The result is not an error but a race, and races produce precisely the duplicates you were trying to avoid. So exactly one path stays active per object. The condition that decides which one is verifiable, not a matter of taste.

There are two options. The first is create or update in a single step (upsert). It is allowed when a verified unique key exists in the destination (external ID). Verified means four things at once: the field is reachable through the interface, it is genuinely unique, its formatting is normalised, and the connecting tool can read it. The second option is look up first and create only after a clear no-match. That applies whenever the key is unverified, ambiguous or unreachable.

The third row is the one most often skipped. Stopping feels like a failure, but it is a result: the system is saying it cannot resolve the situation safely and is handing the decision to a human. Creating automatically at that point would not be a fix. It would be a guess written to your CRM.

One confusion reliably costs a round. An internal key a team uses to spot its own duplicates is not yet a unique key in the sense of the interface. It becomes one only after all four conditions above are confirmed individually.

What do you test with?

Where no fixture has been prepared, the first real buyer becomes the test, and the first mistake goes outside the company. That is the one failure in this whole chain that cannot be fixed internally. A prepared record costs ten minutes and removes exactly that risk.

You need one clearly marked test organisation and one reachable internal address. The organisation carries the fields the destination requires, the attributes used for matching, and any do-not-contact field that appears in the path. Add an empty slot for the IDs the destination will return. The first run needs nothing more than that.

Our position: the test belongs inside your own house, and it stays after acceptance. Deleting the fixture gives up the ability to prove in five minutes, after the next change, that the chain still holds. What does get cleaned up are intermediate tables and fields nobody reads any more.

During the test every writing step stays on manual. Sending goes to named internal recipients only. Real audiences and automatic schedules stay outside the test path, otherwise a campaign starts while the check is still running.

Why does only the second run settle it?

After one successful run many teams treat the matter as proven. But duplicates are not created on first contact, they are created on the second, and the second touch is the normal case: the same company reappears in the next list. Testing once means never asking the question that actually matters.

In the first run a single record travels the entire path. Afterwards you do not look inside the tool, you read back from the destination. Is there one organisation, is there one person, is the person linked to the right organisation, is the event attached to the right person, do owner, sender, channel and timestamp match what was agreed. The returned IDs and the timestamp get recorded.

In the second run the same record travels the same path again. Only this run answers the question the decision maker actually has.

The second run gets a new run ID but keeps the event IDs from the first, so deduplication can be observed at all. Five green rows are the first dependable result of the entire project. Four green and one red is a finding that costs twenty minutes now instead of a campaign later.

That this chain carries when it is built properly shows in one of our own case studies: node.energy — "5x More Demos with AI-Powered Outbound on Clay & HubSpot". The same handover between enrichment, CRM and sending, except verifiably tested before the first campaign ran.

What has to happen when something breaks?

Failure cases usually get discussed once they show up in a live campaign, under time pressure. Agreed in advance they cost half an hour. Agreed afterwards they cost a stopped campaign and an explanation to the client. Only test the cases that genuinely occur in this company's real path.

A reply from the recipient belongs in the same logic. If a reply should stop further automatic touches, that is a check line and not a setting you assume works. In the sending tool, usually Lemlist for us, it gets triggered once for real during the test and then read back in the CRM.

A sync is ready for acceptance when a second person can identify the path from the surface names, when exactly one active route exists per object, when every writing step is on manual, when the fixture is internal and clearly marked, and when both runs exist with destination readback. Only then do placeholders get replaced by the real saved actions, and the test release gets separated from the production release.

Our position: stopping is a result, not an outage. A system that halts on ambiguity costs one manual step. A system that guesses costs a cleanup and the trust of a recipient who should never have received that email. How fast a verified chain can go live shows in a second case study of ours: knk — "24/7 AI-Automated Sales Pipeline in <6 months".