Which phone number survives when someone corrects it in CRM while the order system sends an older value? Once both systems are known to refer to the same customer, another question begins: who may update each value, and which rule resolves continuing differences between sources?
Identity matching does not settle update authority
A fictional workwear supplier uses CRM and an order system. The first contains a corrected phone number; the second sends a different delivery address with one component blank. These synthetic examples support a purchasing discussion, not an executed sync. The issue is continuing values on a known record, beyond duplicate detection.
Sales may own the general contact number while a delivery address belongs to a particular order. “CRM is the master” cannot resolve every field. Establish whether a value describes the customer generally or one transaction; applying a shipment address across the whole record may contradict business intent.
Agree authority per field or related group
Have data owners approve this table with the implementer. Priority should follow an operating reason rather than the better-known product name, with authority to change it specified. If customer state or transaction type changes the rule, document that condition explicitly for testing.
| Field or group | Update authority | Blank and conflict handling | Acceptance evidence |
|---|---|---|---|
| Contact phone | Approved source and transfer direction | Unknown value or explicit clearing request? | Correction followed by conflicting value |
| Address group | Should components travel as one unit? | How is a mixed-source address prevented? | Complete and partially empty addresses |
| Recency-controlled value | Definition of trusted change time | Missing or equal timestamps? | An old change arriving after a newer one |
This defines intended outcomes, not universal connector features. The implementer identifies supported behavior and any custom rule or authorized human review required. Unsupported cases belong in scope and cost discussions before becoming post-launch surprises.
A blank needs an agreed meaning
An empty field may mean unknown information, intentional removal or incomplete import. Do not silently equate them. In the example, an absent building number should not automatically authorize clearing a documented address; the data owner defines the required outcome and includes it in the sample.
HubSpot's custom-object sync documentation describes a preferred application for discrepancies, with a blank in that application not replacing the other value, subject to sync direction. This is behavior for a particular path, not every connector or proof that global application priority meets your case.
Avoid constructing a fact no source supplied
Customer Insights explains that field-by-field selection can mix address components, while grouping related fields supports choosing them together under a merge policy. Recency needs a ranking reference. These are unified-profile rules; a winning value there does not establish write-back into operating systems.
Trace the outcome to its actual use: an analytical display, CRM update or future orders. That decision determines the evidence required. A polished unified screen does not establish identical changes to every underlying source.
Four events reveal the real agreement
Request an authorized plan covering corrected phone then old value, conflicting changes, a blank and a partially changed address group. Record before-and-after values, source, event time and decision evidence. This article performs no API call or real-data modification.
If the rule uses “latest,” establish whether that means field modification, message arrival or whole-record update time. Different definitions can change results. Document behavior when timing information is missing rather than inventing a certain sequence for unknown events.
Name the conflict decision owner when automation cannot decide, closure evidence and approval for later rule changes. Preserve the agreement version used by the sample. A manual correction that leaves the same cause active may let the next cycle restore the wrong value.
Integration discovery questions help define scope. Bring the field-authority table and conflict cases when discussing system integration with Nextwave to specify continuing behavior after customer identity is established.
Value policy references
Relevant HubSpot custom-object synchronization and Customer Insights field merging sections were read on 4 November 2026. Prepared with AI assistance and information and translation review, without running synchronization or changing rules or data.
