Who Owns the Data? Define a Source of Truth

Two systems can both hold a customer record while owning different parts of it. Problems start when each can silently overwrite the same field. Map the authoritative source for every important value, the event that changes it, and the response to a conflict.

Classify fields

A CRM may own sales contact details while an operations platform owns service-site access notes. Treat copied values as projections and preserve the source identity and update time.

Write conflict rules

Choose whether one system wins, staff review is required, or a value is never synchronized back. Avoid 'latest timestamp wins' when clocks, offline edits, or business meaning make it unsafe.

Reconcile regularly

Provide a report of missing or mismatched identifiers. Integration success logs do not prove the two systems still agree on their business records.

Publish a field ownership matrix

For each important field, name the authoritative system, who may change it, the event that distributes the change, and the consumer's expected freshness. Customer identity, billing address, service-site contact, and technician notes may all have different owners even when they appear on one screen. Treat copies as projections with source identifiers and update times. Mark fields that must never sync backward. This matrix gives developers a contract and gives operators a way to explain why one screen differs from another while an update is in flight.

The field ownership matrix should be specific enough to resolve a disagreement. For each field, include source identifier, authoritative system, permitted editor, update event, recipient, freshness target, and conflict action. Add sample cases where the website, CRM, and field platform each hold a different value. Have the relevant business owners agree on whether those values refer to the same person or place before writing sync code. Mark merge and deletion behavior as carefully as ordinary updates. Keep the matrix versioned beside integration contracts so a later system change does not silently transfer authority to a copy.

Design conflict and merge cases

Test a customer merge, a deleted record, an offline field edit, a failed delivery, and two updates arriving out of order. Decide which cases can be resolved automatically and which require a human because business meaning is ambiguous. Preserve the original values and resolution history so a correction is auditable. Run reconciliation reports against stable identifiers, not just successful API calls. If two systems disagree, the report should point to the owning source and a repair action. Without this work, 'source of truth' remains a slogan that breaks as soon as the normal workflow changes.

Decision checklist

• List important records and fields.
• Name the system allowed to create and change each one.
• Define deletion and merge behavior.
• Run a reconciliation sample after every integration change.

A small test before committing

Choose ten fields that are copied between two systems. For each, name the business owner, write authority, update event, propagation delay, and conflict rule. Change one value in each direction in a staging environment and inspect what both systems show afterward. A field with no authoritative writer or correction path will drift. Use the test to establish ownership at field level instead of declaring one entire database the source of truth.

Worked scenario

A hypothetical customer changes a phone number in a website form while a dispatcher edits a site contact in the field app. Those may be different people. A well-designed integration keeps the identities distinct instead of replacing one number with the other.

For a scoped application of this decision, see Systems & Data Integration.