Stork Delivery
Which system owns the customer record?
A reliable integration needs rules about who owns each field, including what happens when two systems disagree.
The problem: connected systems keep overwriting the right customer data
A customer changes their delivery address in a portal. Sales corrects it in the CRM. The ERP still has last month's address, and an overnight synchronization is about to run.
Which address wins?
An integration cannot answer that question through connectivity alone. The business needs an ownership rule, and the software needs a way to enforce it.
A practical approach
Assign ownership by field
It is tempting to declare one application the source of truth for the entire customer. In practice, different systems may own different facts.
The CRM might own sales contact details. The accounting system might own payment terms. A customer portal might accept address-change requests without being allowed to approve every change automatically.
Write these responsibilities down at field level for the information that matters. Include who can change it, where changes are accepted, and which systems receive the result.
Keep identity separate from description
A business name or email address can change. Neither is a dependable substitute for a stable record identifier in every situation.
Maintain the mapping between each system's customer IDs. Decide how duplicates are detected and who can merge records. When a merge happens, retain enough history to explain why an old identifier now points somewhere else.
Consider a company with several billing accounts and multiple delivery sites. Treating all of them as one record because the company name matches can create mistakes that look like synchronization failures.
Make conflicts visible
“Last update wins” sounds simple until clocks differ or an old export arrives late. It can also allow a low-authority system to overwrite a more carefully controlled value.
Where an automatic rule is inappropriate, create a reviewable conflict. Show the competing values, their sources, and when they were recorded. Give someone the authority to resolve it, then apply that resolution consistently.
Test the uncomfortable cases
Before turning on two-way synchronization, test a renamed customer, a duplicate, a deleted contact, and two near-simultaneous updates. Include an unavailable downstream system and a replay of yesterday's data.
Success means more than moving fields from one screen to another. It means the team can explain why a record has its current value and can correct it without fighting the next synchronization.
Those ownership decisions are part of systems integration. They belong in the design conversation, not in a spreadsheet someone discovers after launch.
The result: customer changes that stay corrected
Start with one disputed field, such as a delivery address. Document its authoritative source and conflict rule, then exercise simultaneous changes and a replay of old data. The resolved value should reach its intended destinations and remain correct after the next synchronization. Operations should be able to trace the decision without asking an engineer to inspect raw logs.