Two-way CRM sync needs field-level ownership

The last update is not always the right update

A sales representative corrects a customer's phone number in the CRM. An overnight import then sends the older number from an operational database and overwrites the correction. Both systems report a successful sync.

The failure is a missing ownership rule. Last-write-wins uses timing to decide authority, but timing may reflect batch schedules or delayed delivery rather than the quality of the information.

Start with the business purpose of each field. Sales qualification may belong to the CRM, while an operational account status belongs to the service that performs fulfilment. A shared contact record does not require a single owner for every property.

Describe the direction and clearing rule

For each synchronised field, record the authoritative source, permitted destinations and what an empty value means. Omission, explicit clearing and an unknown value should not be merged accidentally.

A source that omits a field because it was not selected in an API query must not clear the destination. Likewise, a deliberate removal should not be ignored as if no change occurred.

Keep identity independent from editable values

Use a maintained mapping between system record identifiers. Email addresses and names can change, so treating them as permanent cross-system identity can create duplicates or attach updates to the wrong record.

Provider APIs may support lookup by several identifiers, but the integration still needs to decide which relationship it trusts. Record merges and account reassignment require explicit handling.

Test the identity mapping separately from field conversion. A perfectly formatted phone number is harmful if it is written to the wrong contact.

Prevent feedback loops without hiding real edits

When the integration writes a value, the destination may emit another change event. Recognise the expected echo through provenance and the operation's known result where the platform supports it.

Do not suppress every event arriving shortly after a write. A user can make a legitimate edit during that interval. Compare the relevant value and change evidence instead of using time alone as a blanket filter.

Give conflicts a business owner

Some fields genuinely accept edits in both systems. Define a merge rule only where the data supports it. Otherwise preserve both proposed values and request a decision from the responsible team.

The integration should make disagreement visible rather than repeatedly overwriting it until the dashboards agree. A dependable sync preserves the intended business authority, not merely identical database fields.