Single source of truth in integrations: where to store the primary customer, order and status information

Primary information should be stored in the system responsible for creating, validating and correcting the relevant business fact. CRM should not automatically own all customer data, and ERP does not necessarily determine every order status. Different fields for the same customer or order may belong to different systems, but each field and status dimension should have one authoritative source.

A single source of truth in integrations therefore does not mean one database for the entire organisation. It means clear responsibility: which source may change a particular fact, where its current version is stored and how other systems receive a controlled copy. This approach makes it possible to design data flows without guesswork or uncontrolled two-way synchronisation.

What a single source of truth in integrations means in practice

A single source of truth, or SSOT, is a rule stating that a particular business fact has one authoritative source. If sources disagree, the value from that source is treated as correct until it is amended through a defined process.

It is important to distinguish between four concepts:

•          Authoritative source stores and confirms the current business fact.
•          Copy receives data for use in another system but does not determine it.
•          Read model combines information for convenient display, search or reporting.
•          Historical snapshot preserves a fact as it existed at the time of a particular event.

For example, CRM may be the primary source for a customer's contact person, while an order retains a snapshot of the delivery address that applied when the purchase was made. A later address change in CRM must not overwrite the history of an order that has already been fulfilled.

SSOT is not synonymous with a data warehouse either. A data warehouse may be authoritative for approved management reports, but it is generally not the place where a customer address is corrected operationally or a fulfilment status is changed.

Why one system cannot automatically be declared the primary source

A common mistake is to choose a system based on its name: customer data belongs to CRM, orders to the e-commerce platform and money to the accounting application. This is an understandable starting point, but the system category alone is not enough.

The authoritative source is determined by responsibility and process:

1. In which system does the fact first arise?
2. Which role may approve or change it?
3. Where are required fields and business rules validated?
4. The unavailability of which system would actually stop the process?
5. Where must it be possible to explain who changed the value, when and why?
6. Which system manages the lifecycle of the specific object?

The system with the most fields is not necessarily the primary source. CRM may contain an invoice number for convenient reference, but that does not make CRM the owner of the invoice. Similarly, a customer portal may show a consolidated order state even though its components come from order, warehouse and payment systems.

In practice, identifying the owner of an object may not be enough. Where necessary, the owner of each field must also be defined. Commercial customer relationships may be managed in CRM, legal details in the system where they are verified for invoicing, and marketing communication preferences in the solution where those preferences are collected and administered.

Status is not one universal field

The field called “status” usually causes the most disagreement. A single order may have several independent states at the same time:

•          order acceptance status;
•          payment status;
•          picking or service fulfilment status;
•          delivery status;
•          invoice status;
•          summary status shown to the customer.

If all these meanings are placed in one free-text field, the integration cannot determine what “processing” means or who may change the value. A safer model separates status into dimensions. The payment system determines the payment outcome, the warehouse or work management system determines fulfilment progress, and the carrier's system determines delivery events.

The status shown to the customer may be a derived projection. For example, an interface may display “preparing your order” based on a confirmed payment and picking that has begun. This projection is useful for communication, but it must not overwrite the underlying statuses in their source systems.

Allowed transitions must be defined for each status. If an order has been cancelled, an integration must not accidentally return it to “new” simply because a delayed event arrives. Database constraints can help protect local data rules. The PostgreSQL documentation explains how constraints keep data compliant with specified requirements. Rules spanning multiple external systems must, however, also be implemented at the integration and process levels.

A method for identifying the authoritative source

The decision can be made through a verifiable sequence instead of simply agreeing on a “primary system” in an architecture meeting.

1. Create a list of business facts

Do not begin with system names. List the facts used by the process: customer identifier, company name, contact person, delivery address, order lines, price at the time of agreement, payment outcome, fulfilment stage and delivery number.

For each fact, record where it arises, where it is corrected, who needs it and whether its history must be retained. This reveals fields that are currently edited in several places without a priority rule.

2. Identify the business owner before the technical owner

The location of a database is not the same as responsibility. The business owner defines the meaning of the value, its quality requirements and the permitted changes. The technical owner maintains the system and integration.

If no role can explain who approves a customer merge, order cancellation or status correction, a new API connection will not solve the problem. A process decision must come first.

3. Create an ownership matrix

For each field or group of facts, specify:

The table values must be adapted to the particular organisation. The table makes responsibility for each fact visible, but the allocation shown here is not a universal division between systems.

4. Agree on identifiers

A name or email address is not a reliable technical identifier. Every customer and order needs a stable identifier, while an integration often also needs to retain mappings to identifiers used by other systems.

It must be defined what happens when customer records are merged, a record is deactivated or an order is created before the customer record. Identifier mappings must be stored in a controlled location. Otherwise, a correction for one customer may be applied to another record.

5. Describe the write and read paths

If a user changes information in the customer portal, that does not mean the portal becomes its source. The portal may send a change command to the authoritative system, receive confirmation and only then update the display.

Consumers need to know whether a received value has been confirmed, is awaiting processing or is merely a cached copy. If the source is unavailable, the choice must be deliberate: block a critical change, place the request in a queue or permit read-only access. Silently writing to a local copy in the hope of “fixing it later” is difficult to control.

6. Define the data contract

The data contract should describe field meanings, formats, mandatory fields, allowed status values, timestamp interpretation, versioning, and deletion or merge semantics. It should also state whether an event contains the full state of an object or only a change.

Without this agreement, two systems can technically exchange the same field while interpreting it differently. For example, “order date” may mean the time of creation, confirmation or payment.

An illustrative customer and order model

Suppose an organisation uses CRM, an order system, a work management solution and a customer portal. This example illustrates the allocation of responsibility and is not a ready-made architecture template.

CRM manages the commercial profile of prospective and existing customers. The order system creates the order and stores its lines, price, currency and the details used at the time of ordering. The work management system determines the actual fulfilment stage. The portal combines data for reading and sends change requests to the appropriate owner.

In this model, the portal does not contain “another truth”. If a customer asks to change the delivery address for an active order, the portal sends the request to the order system. That system checks whether the change is still permitted at the current fulfilment stage. Changing the contact address in CRM does not by itself overwrite the order snapshot.

The notification shown to the customer may, in turn, be calculated from several sources. It is important to retain the ability to explain which underlying facts produced it rather than storing only a vague summary.

How to move data between systems

A write request should be routed to the data owner, while other systems may be notified of changes through events. The Publisher-Subscriber pattern described by Microsoft separates the publisher from consumers and allows multiple recipients to respond to a published event. This does not remove the need to define an authoritative source: the event publisher must have the authority to report the particular fact.

Local, interrelated database changes should preferably be completed in a single transaction. The PostgreSQL transaction documentation describes a transaction as a set of operations that either completes in full or does not take effect. API calls to several independent systems, however, cannot simply be treated as one local database transaction.

If a process completes only partially, retries, intermediate states and sometimes compensating actions are required. Microsoft's description of the Compensating Transaction pattern emphasises that, in an eventual consistency environment, compensation may be a separate business process rather than an exact technical reversal of operations in the opposite order.

Moving from multiple “truths” to one source

In an existing environment, an authoritative source cannot be introduced safely through a configuration change alone. A practical transition includes these steps:

1. Inventory the fields, integrations and places where users correct them.
2. Find conflicting values and determine how they will be resolved.
3. Select an owner for each fact and document exceptions.
4. Put identifier mappings between systems in order.
5. Stop uncontrolled two-way editing.
6. Synchronise the initial data and validate a sample against business rules.
7. Switch the write path to the selected source.
8. Monitor errors, delays and manual corrections before disabling the old path.

Conflicts should not be resolved automatically using the latest timestamp. A later record may be an outdated import or an incorrect manual change. Priority should follow data ownership and status transition rules and, where necessary, human review.

How to verify that the model works

The outcome of an SSOT implementation can be assessed using operational metrics:

•          number of records without a corresponding external identifier;
•          cases where sources contain different values for the same fact;
•          synchronisation delay and the queue of failed events;
•          number of unauthorised status transitions;
•          cases of manual data correction and duplicate entry;
•          changes for which the source or initiator cannot be identified.

It is not enough for copies to match. The organisation must also verify that the business process continues predictably when a system or integration is temporarily unavailable.

Limitations and risks

A single authoritative source can become a dependency point within a process. Its availability, fallback operating mode and recovery must therefore be planned. The fallback mode must not, however, quietly create a second permanent source.

Not all data should always be overwritten with the current value. Orders, contracts and other historical transactions may require snapshots. The current customer profile must be distinguished from the fact used for a specific transaction.

An audit log is generally not the source of the operational fact either. It helps explain the history of changes, but the current value should be determined by the domain system. Data in an analytics platform, meanwhile, may be deliberately delayed and unsuitable for operational decisions.

More copies increase governance and access risks. Every copy should have a justified use, access rules, a retention period and a deletion process. SSOT does not automatically resolve poor data quality: an incorrect record in the authoritative source will simply propagate more consistently.

Checklist before implementing an integration

Before development begins, the team should be able to answer unambiguously:

•          What is the authoritative source for each field and status?
•          Do other systems store a copy, snapshot or derived projection?
•          Who may initiate a change, and who approves it?
•          How are identifiers linked?
•          What happens to a delayed, repeated or unauthorised change?
•          How does the process operate while the source is unavailable?
•          How will conflicts be identified and synchronisation quality measured?

Conclusion

The right location for primary data is not necessarily the most technically central system. It is the system entrusted with business responsibility for the particular fact and its lifecycle. When each field and status dimension has one owner, the other systems can be designed as controlled consumers rather than competing sources of truth.