Skip to main content
By Jonas AnderssonCo-founder
5 min read

Definition

What is a single source of truth?

The question is often not whether your data is correct. It is which copy of it you believe. The customer count in the CRM, the number in the board spreadsheet, and the figure on the dashboard are three different values, and the meeting starts by deciding which one to trust before anyone can act on it. The data exists. What is missing is agreement about which version is authoritative.

A single source of truth is an explicit agreement about authority for a fact: which record or rule governs it, and how other copies are brought into line. It does not require one system to hold everything. A copy can lag or use a different format without becoming a competing authority; the team must be able to explain the difference.

What it is not

A single source of truth is smaller than it sounds, and easier to lose than it looks.

The CRM may own deal stage while finance owns invoice status. Define the fact before choosing its authority. Even two correct reports can show different customer totals when they count different populations or reporting dates.

Three misreadings

What it does not mean

It does not mean one system for everything. Assign authority to the specific field or defined measure, not automatically to every value in a tool.

Copies can still exist. A report or cache may show an older value; record its refresh point and reconcile it under the agreed rules.

An edit may originate through another interface. What matters is that it follows the authority and conflict policy rather than silently overruling a competing record.

How teams lose it

A source of truth rarely fails on day one. It erodes in three familiar ways.

The editable export

A copy becomes a second original

Someone exports the CRM to a spreadsheet to work faster, edits it there, and the spreadsheet quietly becomes more current than the system it came from. Now there are two originals, and the more trusted one is the copy nobody can govern.

The two-way sync

Both systems can change the same field

A two-way sync needs a policy for competing edits. Some implementations use last-writer-wins, but that is not inevitable. Others reject stale updates, route conflicts to a reviewer or permit different systems to own different fields.

The failure is an unexplained overwrite: someone changes a value without knowing which authority or version the integration will accept. A later timestamp alone does not establish that the new value is correct.

The trusted side channel

The real number lives in someone's head

The system says one thing, but everyone knows to ask a particular person for the "real" figure. That person is now the source of truth, undocumented, unavailable on holiday, and impossible to audit. The system has been demoted without anyone deciding to demote it.

Fictional customer C-204

Agree authority before the copies disagree.

This example team assigns the fields below explicitly. These choices illustrate an agreement; they are not rules for every CRM or billing system.

FactAuthority in this exampleHow another system uses it
Relationship ownerCRM customer recordBilling reads the assigned owner; it does not replace it.
Invoice statusBilling invoice recordCRM displays the billing result and its refresh time.
Billing addressVerified billing customer recordCRM may submit a proposed change for validation; a stale copy does not silently overwrite it.

Two competing address updates

A version check finds a conflict; it does not choose the address.

  1. 01

    Both tools read the same version

    CRM and billing read C-204 at example version 7. Record identifiers establish that the proposed changes concern the same customer.

  2. 02

    Billing accepts a verified change

    Billing records the new address under this team’s authority policy. The earlier version is now stale.

  3. 03

    The older CRM request arrives

    A version-aware implementation can reject the stale write and retain the proposed value for review. Do not assume that every connector has this capability.

  4. 04

    Resolve and verify the copies

    The accountable owner checks the evidence for the proposed address, records the accepted result and confirms that the CRM copy reflects it. Unresolved evidence remains a conflict, not a silent overwrite.

The authority test

When copies differ, can you explain which fact is authoritative and how the difference will be resolved?

A refresh delay, a formatting difference and a genuine competing edit need different responses. Authority is useful when it gives the team a clear rule for that distinction and a named owner for unresolved conflicts.

Key takeaways

  • Define authority for a specific fact, including the rules for updating it and reconciling other copies.
  • It does not mean one system for everything. It means one authoritative answer per field.
  • Two-way updates need an explicit conflict policy; silent last-writer-wins is not an inevitable feature of synchronization.

If you only remember one thing

Authority should explain how a disagreement is resolved, not merely declare which tool wins.

Continue the thinking

Connections

Sources

References behind this piece

  1. Government Data Quality Framework: guidance

    Government Digital Service

  2. Conditional operations using the Dataverse Web API

    Microsoft Learn

    An example of stale-version detection with ETags; it does not decide business authority.

Jonas Andersson, co-founder of Mannvit Labs

Written by

Jonas Andersson

Co-founder, Mannvit Labs

Co-founder of Mannvit Labs, leading systems, data, automation, and technical delivery. He spent four years before this running e-commerce for a Swedish retailer, from SEO to campaigns.

He builds the internal tools and data workflows these guides come out of. See the builds.

  • Commercial data & reporting
  • CRM data quality
  • Process optimization