CRM Data Sync FAQ: Deduplication, Field Mapping, and Conflict Resolution Answered

CRM sync breaks in quiet ways. Records duplicate. Field values flip back and forth between connected systems. An enrichment tool overwrites data a rep manually corrected. By the time anyone investigates, months of contact history are inconsistent across four platforms.

These are the questions that come up most often when teams are diagnosing CRM sync problems or setting up integrations for the first time.

Deduplication

How does CRM deduplication actually work?

Deduplication identifies records that represent the same person or company and either merges them, blocks the duplicate from being created, or flags it for review. Most CRMs match on email address as the primary key, with secondary matching on name and domain.

The process breaks into two stages:

Blocking: preventing duplicates at creation time. When a new contact is created, the CRM checks if a record already exists with the same email. If it does, the system blocks the creation or routes to a merge prompt.

Matching: finding duplicates that already exist. This is a bulk process that scans existing records for fuzzy matches — same first name and company domain, similar email addresses (j.smith@company.com and jsmith@company.com), same phone number across records with different email addresses.

What matching rules should I configure?

Start with exact-match on email address as the primary rule. Then add secondary rules in order of reliability:

1. Exact email → highest confidence, merge automatically
2. Same first name + same company domain → moderate confidence, flag for review
3. Same phone number (E.164 format, normalized) + same domain → moderate confidence, flag for review
4. Same name + no email (common in import lists) → low confidence, never auto-merge

Auto-merge only on your highest-confidence rules. Flag everything else for human review. Auto-merging on fuzzy matches destroys data faster than the duplicates would have.

Do I need to deduplicate before importing a list?

Yes, always. Importing a list into a CRM that contains duplicates of existing records creates a deduplication backlog that is much harder to clean than if you had deduplicated the list first.

Before any list import: deduplicate the file itself (remove rows with duplicate email addresses), then run a match against your existing CRM data to identify records that already exist. Import only net-new records.

How often should I run a full deduplication pass?

For most teams, quarterly is sufficient if your import hygiene is good and you have blocking rules active at creation. If you are importing frequently from multiple sources with varying data quality, monthly is better.

Tools to run it: HubSpot's native deduplication tool, Salesforce duplicate rules with a scheduled batch job, or a third-party tool like Dedupekit or Clearbit's matching API for higher-confidence matching.

Field Mapping

What is field mapping and why does it matter?

Field mapping defines which field in System A corresponds to which field in System B. When "Job Title" in your marketing automation tool syncs to Salesforce, does it map to the "Title" field or a custom field called "Contact Job Title"? If the mapping is wrong, data lands in the wrong place — or gets dropped entirely.

Bad field mapping is one of the most common causes of silent data loss in CRM integrations. The sync runs successfully (no errors), but the data ends up in an unexpected field that nobody monitors.

How do I set field mapping rules correctly?

Start by auditing both systems before you configure any sync:

1. Export a list of all fields in System A that you want to sync
2. Map each to its counterpart in System B — field name, field type (text, number, date, picklist), and whether the values match (does "VP of Sales" in one system correspond to the same option in the other system's picklist?)
3. For fields with no direct counterpart, decide: create a new custom field in the destination, drop the field, or transform it into a field that exists

Pay special attention to picklist fields. If "Lead Source" in your marketing tool has options that do not exist in your CRM's "Lead Source" picklist, unmapped values will either fail silently or default to blank.

What transformation logic do I need?

Common transformations you will need to handle:

• Format normalization: phone numbers need E.164 format for matching. Dates need ISO 8601. Text fields need to have leading/trailing whitespace stripped.
• Value mapping: picklist options that mean the same thing but have different labels across systems ("Organic Search" vs "Organic")
• Concatenation: a first-name and last-name field in System A mapping to a single "Full Name" field in System B
• Splitting: a full name in System A splitting into first and last name in System B

If you are using a no-code connector, check what transformation capabilities it exposes. Many support basic value mapping but not complex string operations. Complex transformations need custom code in a middleware layer.

Conflict Resolution

What is a sync conflict and how does it happen?

A sync conflict occurs when the same field on the same record has been updated in two different systems between sync runs. System A says the contact's job title is "VP of Marketing." System B says it is "Head of Marketing." Both were updated by different users at different times. The sync has to decide which value wins.

If you have not defined conflict resolution rules, the outcome is usually "last write wins" — whichever system wrote last overwrites the other, regardless of data quality. This produces silent, unexpected field changes that erode trust in the CRM.

How should I define conflict resolution rules?

Define rules per field, not per integration. Some fields should always defer to a specific system because that system is the authoritative source:

• Job title: defer to the CRM if a rep has manually verified it in a call; otherwise defer to the enrichment source
• Email address: defer to the CRM unless the new email came from a verified bounce or enrichment update
• Deal stage: always defer to the CRM — no external system should overwrite a deal stage
• Company domain: defer to enrichment tools; they are better at normalizing domains than manual entry

The cleanest approach is to designate one system as the authoritative source per field and make all other systems read-only for that field. It is not always possible, but where you can enforce it, do.

What about field-level timestamps?

Some platforms let you use field-level timestamps to resolve conflicts: the most recently modified value wins. This sounds clean in theory but breaks when the system clocks are out of sync, when one system batches updates with a delay, or when "modified" timestamps are reset by platform background jobs rather than actual user edits.

Do not rely on timestamp-based conflict resolution as your only strategy. Use it as a tiebreaker within a field-authority model, not as a replacement for it.

How do I know when a sync conflict has been resolved incorrectly?

You often do not, until a rep notices a wrong value and reports it. To catch this proactively:

• Log every write-back with the source system, the old value, and the new value
• Run a weekly report on fields with high change frequency — these are the fields where conflicts are most likely
• Spot-check ten to twenty records per month, comparing the value in both systems and the sync log

If you are running a no-code integration tool, check whether it provides field-level change logs. Many do not. This is one of the clearest reasons to invest in a custom sync layer when data accuracy is critical.

---

Clean CRM data sync requires getting the setup right before scale — not patching a broken sync after it has corrupted thousands of records.

If your CRM sync has grown complex enough that field mapping, deduplication, and conflict resolution need custom logic, Clixo can help you build a sync layer you can observe, audit, and trust.