How to Choose a Source of Truth Across Business Systems

Authority can change with context

Calling one application the source of truth for an entire customer or order is often too broad. The sales system may control the account owner while accounting controls the credit status and the shipping tool records the delivery event.

Even one field may change authority by legal entity, sales channel, region, business purpose, or lifecycle state. A draft order total, approved order total, and posted invoice total belong to different points in the process even when a screen gives them similar labels.

Record the scope with the field. Also identify combinations that must remain consistent, such as currency with amount or quantity with unit of measure. Two individually valid values can form an invalid record when they come from different business moments.

How a value becomes accepted

Pick a recent record and trace one field from its first entry through every system that displays or changes it. Find out who enters it and what they rely on. Then follow a correction to see where the revised value actually goes.

Separate the business data owner from the technical integration operator and the person who approves exceptions. The business owner defines meaning and authority. The operator maintains delivery and recovery. An escalation contact decides when writes pause or resume after a failure.

A copied value can look official because it appears in a formal system. Its location alone does not establish authority. The responsible business process and the state of the record decide whether the value is accepted for a particular use.

The field authority record

Keep the decision close to the integration map. A short record for each important field gives builders and operators the same instructions.

• Business meaning, data type, units, precision, time zone, allowed values, and blank meaning
• Record type, lifecycle state, business purpose, and conditions that transfer authority
• Authoritative system, business data owner, and exception approver
• Systems allowed to display a value or propose a correction
• Normalization rules and whether the value is entered, calculated, or copied
• Expected timing, stale threshold, and decisions allowed to use a last-known value
• Supported correction model, required history, and conflict route
• Technical operator, failure contact, and person allowed to resume writes

Identity, merges, and removals

Keep a controlled identity crosswalk when the same customer, order, product, or account has different native IDs. The crosswalk should connect each source ID to the accepted identity and retain merge lineage and retired aliases. Define how an incorrect merge is reversed or a record is split again when the systems support it.

A deactivated record, a soft deletion, a permanent deletion request, and removal under a retention rule are different events. Name who may authorize each one and which destinations must delete, retain, or restrict the record. A controlled tombstone or deletion marker can prevent recreation during a later replay, but it should not retain data that the removal rule prohibits.

Posted invoices, settled transactions, and other controlled records may require a reversal, adjustment, or linked replacement instead of an overwrite. The authority record should use the source system's supported correction model.

Merges, removals, restorations, and corrections need stable operation IDs. Replaying the same event should not repeat the effect, and each required destination should acknowledge or expose the resulting state for confirmation.

Preventing loops and stale writes

A connected system may discover a different address or status without having authority to overwrite the accepted value. Keep the proposal separate, along with its origin, observed source version, business-effective time, and processing time. Route it to the system or person responsible for acceptance.

An accepted change should carry a stable change ID, origin system, and accepted source version. Downstream writes need idempotency and echo suppression so a returned copy of the same change does not start another update. Avoid blind bidirectional writes between systems that can both edit the field.

Use a conditional write or compare-and-set when the destination supports it. A version mismatch means the state changed after it was read. Hold that write, read the current value, and evaluate the conflict again instead of retrying the stale update.

Timestamps can help detect delay, although cross-system clocks, precision differences, bulk edits, and late events make the newest timestamp an unreliable authority rule. Prefer committed source versions, sequence numbers, or change tokens where available.

Partial delivery and reconciliation

Track delivery separately for every destination. If two systems accept a change and one fails, keep the accepted states and the failed destination visible under the same change ID. Confirm writes through an acknowledgement or read-back when the destination allows it.

Retries should be bounded and safe to repeat. Keep a checkpoint or watermark for ordered replay, route records that repeatedly fail to a named queue, and decide whether unaffected work may continue. An uncertain write must be reconciled before another attempt can create a duplicate effect.

Build the test set from real record patterns. Cover every lifecycle state, then add the failure cases the connection must survive, including duplicate delivery, partial success, and simultaneous edits. Set acceptance limits and give unresolved differences an owner.

Reconciliation continues after launch. Each run should show what was checked, where processing resumed, what evidence was kept, and who handles a mismatch. Run it after interrupted processing and verify that repeating a correction is safe.

Stale sources and manual overrides

Define how old an authoritative value may be before the workflow pauses or warns an operator. The field authority record should say which decisions may use a labeled last-known value. Work affecting payment, credit, inventory commitments, compliance, or customer communication may need to stop until current data returns.

Store a manual override in a controlled location with its field, record, source version, approver, reason, scope, and expiration. State whether separation of duties applies and which automatic writes pause while the override remains active.

Protect the override with a conditional write or equivalent version check. On expiration or source recovery, route it to an explicit outcome: accept it into the authoritative system, replace it with the current source value, or send the conflict for review.

When an authority rule changes

Revisit the field decisions when a system, owner, form, import, lifecycle rule, or correction method changes. The business data owner should approve the revised meaning and scope. Give the integration service only the systems, records, fields, and actions allowed by the map.

Test the affected conflicts, partial failures, overrides, and recovery path before normal writes resume. The technical operator should restart delivery only after the owner reviews the agreed evidence and approves it.

Operators need a clear way to flag an incorrect conflict result. The report should include the field, affected record, current authority rule, and rule owner so the business can decide whether the record or the rule needs correction.