Your systems disagree. Pick who gets to be right.
Two-way sync cannot decide who owns a customer address. Define field ownership before your integration spreads the wrong answer.
Two-way sync sounds like cooperation. Sometimes it means two applications taking turns overwriting the correct address.
The connector can be working perfectly. Every request succeeds, every record arrives, and the business still sends something to the wrong building. Congratulations on the excellent plumbing. The water is coming through the ceiling.
At Background Craft, our starting question for an integration is who gets to change each fact. A system can own billing details without owning delivery instructions. Treating an entire customer record as the territory of one application is convenient until the people doing the work disagree.
Follow one customer through a move
Consider this fictional lifecycle for a business that supplies equipment to commercial customers. It uses a sales system, an accounting system and a dispatch system. This is a design example, not a client story.
When sales creates a customer, the business assigns a stable customer identifier. Each application has its own local record ID, so the integration keeps an explicit mapping between them. Neither the company name nor its address is the identity. Customers can change both without becoming new customers.
Initially, sales records the contact and proposed delivery address. Accounting approves the billing details. Dispatch confirms the delivery location for the first order. The word “address” now refers to different facts, and flattening them into one field would be a stupid shortcut.
Later, the customer moves its warehouse but keeps its billing office. A dispatcher confirms the new warehouse address. Dispatch owns the current delivery location, so that approved change goes to the delivery-address view in sales. Accounting’s billing address stays untouched.
An old sales import then arrives with the previous warehouse address. Its import timestamp is newer than the dispatch edit. “Last write wins” would put the old address back. The ownership rule instead treats the sales value as a conflicting proposal. The current delivery address remains, and the discrepancy goes to the operations role responsible for delivery data.
The order already on a truck needs a separate decision. Its destination is a snapshot approved for that shipment, not a live mirror of the customer profile. Operations decides whether to redirect it. Future orders use the newly confirmed location. Otherwise a harmless profile edit could quietly rewrite an active delivery.
Empty is not an instruction
During the move, sales imports a spreadsheet with an empty delivery-instructions cell. That could mean nobody collected instructions. It could mean the export omitted them. It does not automatically mean “erase the loading-bay instructions dispatch verified yesterday.”
Define separate meanings for an absent field, a blank value and an explicit removal request. For this fictional business, omitted fields leave existing values alone. Blank instructions from sales create no change. An authorized dispatcher can explicitly clear obsolete instructions, with a recorded reason.
That distinction needs to survive the connector. If an application represents both “unknown” and “delete” as the same empty string, the integration needs another signal or a review step. Pretending the ambiguity disappeared because the API accepted the payload is bullshit.
Write the ownership agreement
Use a worksheet before configuring the mapping. Complete one row per business fact, including facts that happen to share a label.
| Decision | What to write down |
|---|---|
| Field and meaning | Current delivery address, distinct from billing address and shipment destination. |
| Identity | Stable customer ID and the maintained mapping to application record IDs. |
| Authority | Which system and business role can approve a change? |
| Other editors | Can they submit proposals, or should their edit controls be disabled? |
| Empty and removal | What do omission, blank and explicit deletion mean? Who can remove a value? |
| Timing | When does the value take effect? Which historical records stay unchanged? |
| Conflict owner | Who reviews disagreement, and where does that work appear? |
| Repair | Where is the correction made, and how are dependent copies checked? |
A field without an owner is an unresolved business decision. Assigning the connector as its owner does not resolve it.
Reconcile meaning, not just counts
After the move, compare the customer’s mapped records. Check that dispatch and sales show the approved delivery location, accounting retains the billing office, and the active shipment reflects operations’ decision. Matching record counts would prove none of those things.
Run this comparison on a schedule appropriate to the consequences of stale data. Report missing mappings, unauthorized differences and unresolved proposals separately. Repair the authoritative record when it is wrong; repair the downstream copy when it has drifted. Record the resolution so tomorrow’s comparison does not reopen yesterday’s argument.
The useful outcome is a rule a dispatcher and an accountant can both explain. Build the sync after they agree on that rule.