Conflict resolution and overwrite policy: reconciling CRM and provider values
The actual rule for when an enrichment provider's value disagrees with what's already on the record: which field families never get silently overwritten, and how the review path works.
On this page
- Classify every field family before the conflict happens
- The rule that protects practitioner judgment
- What a conflict log needs to capture
- Merges carry the same rule
- GTM Lab: the field that shouldn't move, and the merge that shouldn't run
- Salesforce and HubSpot: what changes, what doesn't
- Conflict resolution checklist
- Where this connects
An enrichment provider returns a job title that disagrees with what a rep typed in last week. Something has to decide which value wins, and "the newest data wins" is not a policy, it's an accident waiting to overwrite verified information with a lower-confidence guess the moment the enrichment job happens to run after the rep's edit.
This page is the operational half of a two-part idea. The CRM field dictionary defines source, authority, freshness, and primary-source status for a field in general. This page applies that framework specifically to the moment an automated enrichment result conflicts with an existing CRM value, and states the actual overwrite rule.
Classify every field family before the conflict happens
Decide the rule in advance, per field family, not case by case when a conflict shows up:
| Field family | Overwrite rule | Why |
|---|---|---|
| Practitioner-owned assessment (a rep's or CSM's judgment call) | Never silently overwrite | The value represents a person's evaluation, not a fact a provider can supersede |
| System-derived, recalculable (a score, a rollup) | Refresh when the source recalculates | The old value wasn't "wrong," it's just superseded by the same kind of calculation running again |
| Firmographic, provider-sourced by default (company size, industry) | Refresh on verified higher freshness, unless a human has overridden it | The provider is the primary source until someone deliberately corrects it |
| Empty field | Fill automatically | There's no existing value to conflict with |
The field dictionary's authority and primary-source classifications (see CRM field dictionary) are what decide which row a given field belongs in. This table doesn't introduce a new vocabulary; it applies the existing one to the specific moment enrichment tries to write.
The rule that protects practitioner judgment
A field classified as practitioner-owned is never silently overwritten by an enrichment result, regardless of the provider's confidence score. "Never silently" doesn't mean "never changes." It means any change to that field, whether from enrichment or a differing internal source, surfaces for review with both values shown, instead of one replacing the other with no trace.
This protects the specific failure this guide keeps returning to: a value that looks fresh and current (because it was just written by a job that ran on schedule) isn't automatically more trustworthy than a value someone verified by hand and hasn't had reason to touch since. Freshness of the write is not the same as freshness of the underlying fact.
What a conflict log needs to capture
When a conflict is detected and routed for review, record enough for someone to actually resolve it and for the resolution to be auditable later:
| Field | What to capture |
|---|---|
| Field ID | Which field is in conflict |
| CRM value | The existing value and its source |
| Provider value | The proposed value and its source |
| Sources | Where each value came from, including timestamp/observation time |
| Review outcome | Which value was kept, or whether both were preserved with a flag |
| Final value | What the field reads after resolution |
Preserving both values, even after resolution, is often better than discarding the loser. A CSM's health assessment and a system's calculated risk score can both stay on the record, disagreeing, with the disagreement itself surfaced as a signal rather than resolved away by picking a winner.
Merges carry the same rule
The duplicate-merge process (see duplicate detection, merge review, and survivorship) uses the same overwrite logic when two records' conflicting field values need survivorship rules. An unsafe proposed merge, where one of the two records is protected (open Opportunity, active CS relationship, recent marketing engagement, or closed-won status), should be blocked from completing automatically and routed to review with the protection reason stated, exactly like a practitioner-owned field conflict is routed to review rather than resolved silently.
GTM Lab: the field that shouldn't move, and the merge that shouldn't run
GTM Lab, a fictional B2B software company, runs an enrichment job against a Ferrow Industrial contact record. The job returns a job title and company-size value that conflict with values a rep entered by hand the previous week. Under the field-family classification, the rep-entered job title is practitioner-owned-adjacent (a recently verified human entry) and the company-size field is provider-sourced firmographic data. The job title doesn't get silently overwritten; it routes to the approval queue with both values shown. The company-size field, having no recent human override, refreshes automatically since it's classified as provider-sourced-by-default.
Separately, a duplicate-merge job proposes merging two records where one has an open Opportunity: the protected-record rule from the duplicate-detection policy applies here too. Rather than merging automatically, the proposed merge is blocked and routed to review with the protection reason (open Opportunity) attached, the same review-not-silent-resolution pattern applied to a merge instead of a single field conflict.
This is a worked example. GTM Lab's specific field classifications are operating choices built on top of the field dictionary's general framework, not a universal rule set.
Salesforce and HubSpot: what changes, what doesn't
Neither platform ships a built-in conflict-resolution layer between enrichment results and existing values; most native and third-party enrichment tools default to either always-overwrite or always-fill-empty-only behavior, and the nuanced per-field-family rule this page describes is a design decision layered on top, usually through custom logic (Salesforce Flow/Apex, HubSpot workflows) or a dedicated enrichment tool's own conflict-handling configuration. Check your specific enrichment provider's current documentation for what native conflict handling it offers before assuming you need to build this from scratch.
Conflict resolution checklist
- Every field family has a stated overwrite rule, decided in advance rather than case by case.
- Practitioner-owned fields are never silently overwritten, regardless of provider confidence.
- A conflict log captures both values, their sources, the review outcome, and the final value.
- The same never-silent rule applies to merges involving protected records, not only to single-field conflicts.
- The field-family classifications reference the field dictionary's existing source/authority/freshness vocabulary rather than a new one.
Where this connects
The classification vocabulary this page applies comes from the CRM field dictionary. The approval-queue mechanics that enforce this policy operationally are covered in enrichment cost controls and approval queues. The protected-record rule referenced above is defined in duplicate detection, merge review, and survivorship.
Related guides
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.