Authoritative business data
What is a system of record?
A system of record prevents one business fact from being rewritten in several places by several people. It defines which source controls when copies disagree, who may change the value, and how every important change can be reviewed. The CRM may own sales assignment while scheduling owns the confirmed appointment and accounting owns the posted balance. One system does not have to own everything, but every consequential fact needs a clear home.
What the term means
Authority needs a boundary
Calling an application the source of truth is too vague when its own fields come from several places.
Assign authority to a fact or domain
For each consequential value, identify what it means, where it is created, which system owns the current value, who may change it, and when that authority begins or ends. The boundary may be an object, field, process stage, or business domain.
For example, the CRM can own the sales representative, the scheduling platform can own the confirmed appointment time, and accounting can own the posted invoice balance. A report may display all three without becoming authoritative for any of them.
Separate authoritative sources from working copies
Other systems may cache, transform, aggregate, or display the same data for speed and usability. Those copies can be valuable without gaining write authority.
Label derived values and their refresh time. A warehouse total, dashboard status, or AI-generated summary may lag, omit records, or apply transformations even when it was built from authoritative inputs.
Write paths
Control where changes enter
A declared source of record is meaningless if every connected system can overwrite it.
Define creation and update rights
Specify which user roles, applications, imports, APIs, and automations may create or change each authoritative value. Important updates should record the actor or automation, time, source, prior value, new value, and reason when the platform supports it. Validation and permissions belong at the authoritative boundary.
Manual correction needs its own rule: who can perform it, what evidence is required, whether downstream systems must be replayed, and how the original and corrected values remain reviewable. Audit history should make a mistake traceable without turning every copied system into another writer.
Prefer directed propagation over accidental loops
Document the normal direction for each field. The authoritative source publishes a change; consuming systems update their copies or calculate derived values. If a consumer needs to request a correction, route that request back through the authorized write path.
Bidirectional synchronization may be justified for some workflows, but it is not a default virtue. Without origin tracking, version rules, and conflict handling, two systems can overwrite each other or keep old data alive.
Reconciliation
Conflict rules belong to the business
An integration should not invent policy when two plausible values disagree.
Do not rely on latest timestamp alone
Last-write-wins can be appropriate for low-risk fields under controlled conditions. It can also let an automated backfill, clock difference, delayed event, or unauthorized edit replace the business-approved value.
Choose a rule based on authority and meaning: authoritative source wins, higher-priority source wins, compatible changes merge, or the record enters a review queue. Record which rule was applied and why.
Make exceptions visible
Monitor records that cannot be matched, rejected writes, stale versions, duplicate identifiers, missing required fields, deletion conflicts, retries, and changes that exceeded the allowed propagation delay.
Give the exception queue an owner, response expectation, permitted actions, and escalation route. Repeated manual correction is evidence that the source rule, mapping, identifier, or process needs repair.
Data integrity
Identity, history, and deletion must travel with meaning intact
Matching the visible field values is not enough to prove two systems refer to the same record.
Preserve stable identifiers and provenance
Maintain the authoritative identifier and any required cross-system identifiers rather than matching solely on changeable names, phone numbers, or email addresses. Record the source, relevant timestamps, transformation version, and processing result needed for reconciliation.
Do not expose internal identifiers as authentication secrets. They identify a record; they do not prove that a caller is authorized to read or change it.
Define archive and deletion behavior
Decide what inactive, archived, merged, corrected, restricted, and deleted mean in each connected system. A downstream retry or old import must not silently recreate a record that was intentionally removed or restricted.
Retention and deletion obligations depend on the data, business, contracts, and applicable law. The technical map should implement the approved policy, not invent it.
Migration
Changing the source of record requires a cutover
Authority should move only after the new write path and its data are proven.
Run old and new roles deliberately
Define which system accepts writes during each migration phase, how changes are captured, how data is backfilled, and how consistency is compared. Prevent users or integrations from writing to both systems without a controlled reconciliation design.
Microsoft architecture guidance for system migration similarly treats validation as a prerequisite before a new domain database becomes the system of record.
Set cutover and rollback evidence
Reconcile counts, identifiers, relationships, required fields, totals, states, permissions, audit history, and representative business cases. Define the acceptable variance, who approves it, when writes switch, what old integrations are disabled, and how rollback would replay changes.
A successful file import or synchronization job does not prove semantic equivalence. The business must be able to make the same decisions from the migrated records.
First review
Build a field-level authority map
Ten decision-making fields are enough to expose whether the current model is real or assumed.
Trace each fact end to end
For each field, record its definition, authoritative source, identifier, creation event, allowed writers, validation, consuming systems, direction, expected delay, transformation, conflict rule, exception owner, audit evidence, retention, and deletion behavior.
Then select real records where the systems disagree. Determine which value should control and whether the current process reliably reaches that result. An unanswered question is a governance gap, not merely an integration detail.
Common questions
What business owners usually want to know.
Can a business have more than one system of record?
Yes. Different systems can be authoritative for different domains or fields. The important requirement is that authority and handoffs do not conflict or remain ambiguous.
Is the CRM always the system of record for customer data?
No. It may own customer identity, sales ownership, or relationship activity while accounting, scheduling, support, consent, or service systems own other facts. Define authority at the level needed for the actual decision.
Does bidirectional sync keep two systems equally authoritative?
Not automatically. It can create loops and conflicting writes. If both systems can update a field, define permitted writers, version and origin rules, conflict handling, and the business owner who resolves ambiguity.
Can a spreadsheet be a system of record?
It can be designated as authoritative for a bounded process, but the business must still address access, concurrent edits, validation, identity, history, backup, integrations, and recovery. The label does not supply those controls.
Research
Sources and further reading
Reviewed 2026-08-24. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.