1.48 min read

Source of Record Principles

What Is a Source of Record?

In any complex system landscape, data exists in multiple places. A customer's name might appear in CRM, billing, the service portal, and the mobile app. But which system is authoritative? When systems disagree, which one is right? This is what Source of Record (SoR) principles answer.

Getting Source of Record wrong is the number one cause of data inconsistency, failed integrations, and operational confusion in telco environments. When ownership is unclear, every system thinks it owns the data — and none of them do.

Three Ownership Types

System of Record (SoR)

The authoritative, master source for a piece of data. When there is a conflict, the SoR wins. All other systems must synchronize from the SoR. Only the SoR should allow direct creation and modification of this data. Example: CRM is the SoR for Customer data.

System of Engagement (SoE)

The system through which users interact with and modify data, but it delegates persistence to the SoR. The SoE provides the user experience and workflow but does not own the data. Example: A self-service portal is a SoE for customer details — it lets the customer update their address, but the change is persisted in CRM (the SoR).

System of Reference (SoRef)

A system that holds a read-only copy or cache of data owned by another system. It consumes data from the SoR for its own purposes but never modifies the master. Example: Billing holds a reference copy of customer address for invoice generation, but any corrections must go through CRM.

Source of Record — SoR, SoE, and SoRef roles in a BSS architecture

Figure 1.4 — Source of Record, Engagement, and Reference relationships

SoR Mapping Across BSS/OSS

Each major entity in the telco landscape should have a clear, documented SoR. Here is the standard mapping based on TM Forum principles:

Source of Record Mapping

Entity	System of Record	System of Engagement	System of Reference	Notes
Customer / Account	CRM	Self-Service Portal, Agent Desktop	Billing, Order Management	CRM is always the master for party data
Product Catalog	Product Catalog Manager	Catalog Design Tool	CPQ, Online Shop, Billing	Single source for all product definitions
Product Inventory (Subscriptions)	Product Inventory / SLM	Agent Desktop	Billing, Self-Service Portal	Tracks what each customer currently has
Commercial Orders	COM (Commercial Order Mgmt)	Sales Channels	CRM (order history view)	COM owns the order lifecycle
Service Catalog	Service Catalog Manager	Service Design Tool	SOM, Product Catalog	CFS/RFS definitions owned here
Service Inventory	Service Inventory	SOM (creates instances)	Product Inventory, Assurance	Running CFS/RFS instances tracked here
Resource Inventory	Resource Inventory	ROM, Network Discovery	Service Inventory, Planning	Physical and logical resources
Network Configuration	Network Elements / Controllers	ROM, Element Managers	Resource Inventory	Actual device configs live on the network

Rules for SoR Governance

SoR Governance Principles

One SoR Per Entity

Every data entity must have exactly one System of Record. No exceptions. If two systems both claim to own the same data, you have a governance problem that must be resolved.

Write Through the SoR

All create, update, and delete operations must go through the SoR (either directly or via the SoR's API). SoE systems must delegate writes to the SoR, never bypass it.

Synchronize From the SoR

SoRef systems receive updates from the SoR through events or synchronization. They never push corrections back — if a SoRef detects an error, it must request a correction from the SoR.

Version and Audit

The SoR must maintain a change history. When data conflicts arise between systems, the SoR's version history is the arbiter.

Document Everything

Every entity in the data model should have a documented SoR owner. This should be maintained as part of architecture governance, not left to tribal knowledge.

What Goes Wrong Without Clear SoR

Real-World Failure Patterns

Without clear SoR: (1) Customer updates their address on the portal but the bill still goes to the old address — because billing has its own copy and isn't synchronised. (2) A product is retired in the catalog but orders still come through — because CPQ caches its own product list. (3) Service inventory says a service is active but the network says it's down — because no one agreed on which system is authoritative for service state.

Multiple systems each maintain their own "master" customer record. CRM has one version, billing has another, the portal has a third. Each is modified independently. Over time, they drift. Customer calls in, agent sees different information depending on which system they check.

Result

Data inconsistency, poor customer experience, failed migrations, compliance risk.

TM Forum Open APIs and SoR

TM Forum Open APIs are designed around SoR principles. Each API (e.g., TMF632 Party Management, TMF637 Product Inventory) is expected to be exposed by the system that is the SoR for that domain. This is a core principle of the ODA component model — each component exposes APIs for the data it owns.

Key Takeaways

System of Record (SoR): the authoritative master source — it wins when systems disagree
System of Engagement (SoE): the user interface — it captures changes but delegates to the SoR
System of Reference (SoRef): a read-only consumer — it caches data for its own use
Every data entity must have exactly one documented SoR — no exceptions
All writes go through the SoR; SoRef systems synchronize from it
TM Forum ODA enforces SoR through component-owned APIs