Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
Also called: SSOT
What the principle actually requires
For each field, one system is authoritative and every other copy defers to it. The common misreading — that everything should live in one platform — is neither achievable nor necessary, and pursuing it usually delays the decision that would actually help.
Per field, not per system
Building the map
List the fields that appear in more than one system. This alone is usually revealing and takes less time than expected.
For each, identify where the value is created or verified by the party who owns it. Authority should follow the point of truth, not convenience.
Name the authority explicitly and record it somewhere durable. An unwritten convention is not a governance decision.
Define the direction of sync and what happens on conflict. "Last write wins" is a choice; it should be a deliberate one.
Instrument divergence. Sample records periodically and count where copies disagree with the authority. Divergence rate is the health measure for the whole arrangement.
Why this matters more than tooling
Where no authority is designated, disagreement between systems is resolved by whoever argues most persuasively or most recently. The same disagreement then recurs, because nothing was decided — only settled. Designating authority converts a recurring argument into a lookup.
Where it goes wrong
Declared but not enforced: an authority named in a document while integrations continue to write both ways.
Chosen for convenience rather than provenance, so the authoritative system holds a stale copy of a value maintained properly elsewhere.
Applied at system granularity, producing an unwinnable argument about which platform is 'the' source when the answer differs field by field.
Set once and never revisited, so an acquisition or a new billing system silently creates a second authority.
RELATED TERMS
Systems of Record
The set of systems that each hold authoritative data for part of the business, and the map of which owns what. The architectural decision underneath every reporting question.
Data Hygiene
The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.
Integration Layer
The connections moving data between systems, and the rules governing direction, timing and conflict.
Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
COMMON QUESTIONS
- What is a single source of truth?
- For any given field, one system designated authoritative, with all others treated as copies. It is a per-field decision, not an instruction to consolidate everything into one platform.
- Can you have more than one system of record?
- Yes, and most organisations should. Billing may be authoritative for contract value while the CRM is authoritative for account ownership. The requirement is that each field has exactly one authority, not that there is exactly one system.
- How do you decide which system is authoritative for a field?
- The system where the value is created or verified by the party who owns it. Authority should follow the point of truth, not the system people find most convenient to read.
- What happens when two systems disagree?
- With a designated authority, it is resolved by rule. Without one, it is resolved by argument, and the same disagreement recurs. The absence of a rule is the actual defect, not the disagreement.
WHERE THIS HAS BEEN APPLIED
Client work and research from RevOps HQ, our consulting practice.
FURTHER READING
How to Audit CRM Data Quality
Six measures that require no tooling, no interpretation and no targets — and that together tell you whether the reporting built on this database can be trusted.
Design Factors in CRM Adoption: Applying Technology Acceptance Research to Revenue Systems
Adoption research identifies perceived usefulness as the principal determinant of system acceptance. This paper applies that finding to CRM implementations and sets out a diagnostic distinguishing design causes from user discipline.
Contingency Factors in Data Governance Design for Revenue Systems
Governance research finds that no single governance configuration fits all firms — the appropriate design depends on identifiable contingency factors. That finding contradicts most of what is sold as governance best practice.
Why Two Dashboards Show Different Numbers
When two reports answer the same question differently, the cause is almost never a broken report. It is an undeclared owner for a field, and it is fixable in an afternoon once you know where to look.
Learn how to apply this: CRM Admin 101
Definitions are the vocabulary. The courses are where you learn to operate it, with the interactive audit tools.
See the course