Data and Business Systems
Choose a source of truth for shared business data
When several systems disagree about a customer, product, or location, choose authority at the field level. Define who can change each value, how copies update, and what operators should do when synchronization fails.
A sales application, dispatch board, and customer portal can show different answers about the same customer. Buying another integration does not resolve who is right. Start with the business decision that depends on the disputed value. Then assign one accountable owner and an explicit rule for accepting changes.
Decide what authority means
A source of truth is the place whose approved value wins for a defined purpose. Treat this as a business agreement, not a database label. The sales team might own a contact preference while dispatch owns a delivery instruction. A single application does not need to own every field.
Create a short register of fields, owners, allowed editors, and consumers. Distinguish a proposed change from an accepted change. Include the business identifier used to recognize the same entity across applications. A matching name alone should not decide identity.
Protect identity before copying values
PostgreSQL foreign keys require referenced values to match a row in the related table. This supports referential integrity, not business ownership.[1] Use such controls to reject broken references after the ownership rules are clear. A valid customer reference can still point to an outdated delivery instruction.
Recommend a stable identifier and a separate mapping for identifiers from other systems. Define how a rejected update returns to its originator. Avoid silent overwrite rules based only on the latest arrival, especially when offline work can arrive late.
Hypothetical example: a delivery instruction dispute
A hypothetical equipment distributor stores billing contacts in its account system and unloading instructions in its dispatch tool. A portal request proposes a new unloading entrance. Dispatch reviews the request before the approved instruction reaches downstream screens.
The portal displays a pending label instead of presenting the proposal as settled. If synchronization fails, a named operations owner checks the failed message and the accepted version. This design adds a review step, but it avoids treating two different decisions as one shared text field.
Agree on the operating contract
Use a small field set for the first implementation. Review disagreements with the people who perform the work, not only application administrators. Keep copies when local availability matters, but show their freshness and the route for correcting the authoritative value.
Central authority creates a dependency. If the owning service is unavailable, decide whether consumers stop, use a labeled copy, or accept a pending proposal. Select the behavior by business consequence rather than a universal availability rule. Ask the field owner to approve one realistic conflict example before the integration starts accepting changes.
- Name the owner of each disputed field.
- Choose an immutable entity identifier and mapping rule.
- Define approval, rejection, and conflict behavior.
- Show when a copied value last synchronized.
- Assign an operator to failed updates and recovery.
