GuidePublished 3 October 2026 · 7 min read

Two-way CRM sync explained: field maps, matching, the echo loop, duplicates, and what should never sync back

The parts of a CRM integration — object and field maps, match rules, triggers, delivery — the four ways a sync goes wrong, how to avoid each, what is worth syncing, and which CRMs Linkubit connects to today.

In short

A two-way CRM sync keeps the same customer in step in two systems: a field map says which field goes where and in which direction, a match rule decides which record is whose, and the sync has to stop changes bouncing back and forth for ever. Done well, the conversation tool writes leads, deals and notes into the CRM your team lives in, and the CRM's edits come back. Done badly, it duplicates records, overwrites good data and loops.

On this page

The parts of a sync
The four ways a sync goes wrong
How Linkubit's sync is built
What to sync, and what not to
Revenue from the CRM, safely
Which CRMs

The parts of a sync

Part	What it decides
Object map	Which kind of record goes where: contacts to this board, deals to that one
Field map	Which field becomes which column, and the direction for each: push, pull or both
Match rule	Which existing record is the same customer — a phone, an email, an id
Triggers	When a sync happens: a lead created, qualified, assigned; a deal opened, won, lost
Conflict rule	What happens when both sides changed the same field
Delivery	Queued with retries, or called in the moment and lost if the CRM is slow

The four ways a sync goes wrong

The echo loop. System A pushes a value; B reports the change; A's rule fires on the change and pushes again; B reports again. Each step works. The bill and the API quota do not. A sync has to remember what it last sent and ignore its own change coming back.
Duplicates. A match rule on something that varies — a name, a phone typed two ways — creates a second record for the same person. Match on a normalised identifier, and link the two records once matched.
Overwrites. A pull that writes a CRM edit over a phone number or email silently changes who a customer is. Identity fields should never be pulled; only your own descriptive fields.
Silent failures. A CRM that refuses a column, a token that expired, a quota hit: if the failure lands in a log nobody reads, the board drifts out of date and everyone assumes it is right.

How Linkubit's sync is built

CRM steps are workflow actions — sync, update a field, add a note, create a record on another board — so "when X, do Y in the CRM" lives in the same place as every other rule, readable and editable.
Every action queues, and the scheduler delivers. A slow CRM never slows a conversation; a refusal shows on the operation with the reason ("monday rejected column status") and a retry. Failures retry over hours; a revoked connection asks to be reconnected.
The echo check lives on the link. Each contact is linked to one CRM record, with a fingerprint of every field last sent. Only fields that changed are sent, and a change coming back that equals what was sent is dropped.
Only your own fields come back. A pull targets a custom field and nothing else; the map refuses a pull into a name, phone or email, a push into a column the CRM cannot write, and a match on a field the map does not send — all at once, before anything runs.
New records can wait for a person. Approval is on by default for new records, so a spam enquiry never lands on a shared board on its own.
A CRM record becomes a contact only through an import with a consent basis, so editing a board can never create people the product will message.

What to sync, and what not to

Sync	Leave alone
Lifecycle stage, qualification, score, owner	Every message — the summary and a link are enough
Deal value, stage, expected close date	A price typed into the CRM back into the catalogue
The answers to your qualifying questions	Identity fields, from the CRM back
Payment status, amount, paid date	Fields nobody on the team reads
A note at each milestone	A note on every message

Revenue from the CRM, safely

Teams that close deals in the CRM want the win to count everywhere. In Linkubit, a CRM status reading Won closes the deal here at the deal's own value — never at a figure read off the board — so the revenue, its attribution to the ad that brought the lead in, and the conversion sent back to Meta and Google all follow. Booking revenue is a rule somebody wrote, never an AI's choice.

Which CRMs

monday.com and Zoho CRM are connected today — the monday guide and the Zoho CRM guide walk through each. HubSpot and Salesforce are planned on the same connector, and the integrations page lists them. For any other system, signed webhooks (on Scale) send every lead, deal and conversation event to any URL — a CRM's own inbound endpoint, Zapier, a sheet — and spreadsheet import and export move records in and out.

What is two-way sync in a CRM?

Changes flow in both directions: a lead qualified in the conversation tool updates the CRM record, and a field your team edits in the CRM comes back. Each field has its own direction so neither side overwrites what the other owns.

Should a CRM sync be real-time?

Near real-time is enough and safer. Queued delivery with retries survives a slow or unavailable CRM; a sync that calls the CRM inside every click fails whenever the CRM does.

How do I stop a CRM sync from creating duplicates?

Match on a normalised identifier like a phone or email, link the two records once matched, and send only the fields that changed. Never match on a name.