When several tools store customer information, saying that one system is the source of truth may be too broad. Billing may own payment state, the CRM may own opportunity ownership and a service tool may own work completion. Define authority for the fields and decisions that matter. Otherwise, an integration can replace a correct value with a newer but less reliable copy.
Map The Fields That Change Business Actions
Start with information that affects routing, service, communication or money. For each field, record the authoritative system, who can change it, which systems receive a copy and what event should trigger synchronization. Distinguish a person, an organization and an opportunity rather than assuming one customer record represents all three.
Use stable identifiers and keep the relationships between systems explicit. Two people may share a company email address, and one person may have several roles. PostgreSQL’s documentation distinguishes unique constraints, which restrict duplicate values, from foreign keys, which maintain references between related records. Those database controls can support a design, but they do not decide which real-world records should be merged.
Decide How Each Conflict Will Be Resolved
For low-risk descriptive fields, a designated owner may be able to correct the value directly. For status fields that trigger actions, require stronger evidence about the event that occurred. A late-arriving update is not necessarily a more recent business event. Avoid using “last write wins” as an unexamined default for every field.
Write rules for disagreement, missing values and attempted overwrites from a nonauthoritative system. Some conflicts should be held for review instead of resolved automatically. Preserve enough history to explain which event changed a record and why. Do not store unnecessary personal information in logs just to make troubleshooting easier.
Walk Through A Conflicting Update
Illustrative scenario: a service system marks a project complete, while a delayed CRM synchronization still shows it in progress. If both systems can overwrite the completion field, the older state may reopen work or trigger another reminder. The rule should identify the service system’s completion event as authoritative for that field and treat the CRM as a recipient.
Now consider account ownership. The service system may contain the name of a delivery coordinator, while the CRM identifies the commercial account owner. These are different roles, not conflicting versions of the same field. Renaming and separating them can eliminate a synchronization problem that would otherwise invite an unsafe overwrite rule.
Test Out-Of-Order And Repeated Events
Ask the integration owner to demonstrate what happens when updates arrive late, arrive twice or arrive after a record has been merged. Check that relationship mappings remain valid and that the workflow does not create a loop of changes between systems. Include a deleted or inactive record according to the application’s intended behavior.
Keep contact restrictions and other sensitive operating controls from being weakened by a stale copy. Apply the business’s approved handling rules and test representative conflicts explicitly. A system that synchronizes names correctly may still mishandle a consequential status. Verification should focus on the actions the data can trigger.
Assign Ownership For Exceptions And Changes
Create an exception queue with the conflicting values, their sources, relevant event references and an accountable reviewer. Give the reviewer a supported correction process. Directly editing whichever database is easiest can bypass the authority rule and cause the next synchronization to undo the correction.
Review the field map when adding a new tool or workflow. A newly introduced application should not silently become another writer for every shared field. Track unresolved conflict age and repeat causes. The objective is a dependable record of business events, with clear limits on automated reconciliation and a practical path for the cases that require judgment.
Common Questions
Should One Application Own Every Customer Field?
Only if that matches the actual operating model. Authority can be assigned by field or event, provided the rules are explicit and the team can explain how conflicts are resolved.
Can Unique Email Addresses Prevent Duplicate Customers?
They can enforce a specific technical rule, but that rule may not match real relationships. Shared, changed or missing addresses require deliberate identity and matching decisions.
Sources And Further Reading
- PostgreSQL: Constraints · Checked 2026-10-26
These sources provide context. Requirements depend on the actual activity and applicable jurisdiction. Business-process guidance does not replace professional advice.