Know where your data belongs

“One source of truth” does not necessarily mean one database. The CRM may know who the customer is, invoicing may know what they owe, and dispatch may know where today’s job is happening. Each can be authoritative about a different fact.

Problems begin when authority is assigned to an application without considering the meaning of its fields. A billing address and a delivery address can match for years and still be different facts. Treating them as interchangeable makes the first exception expensive.

Preserve meaning through a correction

Imagine a customer changes their main address while an existing order is already on its way to the old one. Updating every historical record may erase where that delivery actually went. Leaving everything unchanged may misdirect the next order.

The design needs to distinguish a current profile from the facts of a particular transaction. Both can be correct at different times and for different purposes. “Use the newest value” cannot settle that distinction.

A useful data map records which system owns each fact, who may correct it and which historical relationships must survive. That becomes especially valuable when AI assistants use connected information: a current-looking answer is only as useful as the meaning and timing of the records behind it.

Preserve identity across tools

Names and email addresses can change or be shared. Use stable identifiers where systems support them and retain the relationship between records. Decide how duplicates are recognized and who can merge them.

Consider a hypothetical customer with two locations and several contacts. A simple export that treats every email address as a separate customer may lose the organization structure. Test with examples that represent the real relationships in your business, including changes and exceptions.

Assign responsibility for quality

Someone should be able to resolve an unclear or conflicting record. That person needs both context and authority. An engineer can enforce a required field, but the business must define what a valid value means and what to do when the information is unknown.

The Government Data Quality Framework provides an external reference for treating quality as an ongoing responsibility. A practical starting point is to identify which errors cause the most rework and correct their source instead of repeatedly cleaning their downstream copies.

Keep access and movement deliberate

Record which tools receive important information and why. Send only what they need for the agreed purpose. Make sure the business understands how to export records, attachments and relationships, and who is authorized to do so.

Test the export with a small representative set. Can another person understand the fields? Are important attachments included? Can related records be joined again? An unreadable archive is a weak foundation for continuity or a future migration.

Decide how long information is needed for the work and who can approve its retirement. Retention requirements depend on the data and the business; avoid allowing a tool’s default setting to become an accidental policy.

Make the rules visible

A short map of systems, record types and owners can prevent many integration mistakes. Keep it close to the operating documentation and update it when a new tool is introduced.

Integrations covers the movement between tools. Vendor exit addresses the point when those records must move somewhere new. Both become easier when ownership is clear from the beginning.