One Source of Truth per Attribute
Also in 28 languages
Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 1 of 6 in the chapter Master Data and Identity, chapter 6 of the Data Architect course. Each module stands on its own. Next: The Four Ways to Master Data
The question this module answers: What does “single source of truth” really mean?
There’s a phrase I hear constantly: “We need a single source of truth.” Okay. For what? The customer? That’s not specific enough. Take an account. Who owns the customer’s name, billing address, credit limit, account executive, support tier, marketing preferences? Those answers don’t point to the same system. The ERP may control the legal name, billing address and credit status; Salesforce the relationship owner and sales attributes; another platform the consent. So when someone tells me “Salesforce is our single source of truth for the customer,” my next question is: which truth?
Truth Belongs to an Attribute
Section titled “Truth Belongs to an Attribute”The first principle of master data is this: authority is assigned per attribute, not per record. An account may live in Salesforce without Salesforce being authoritative for every field on it. Seven fields on one record, two authorities:
| Attribute | Authoritative system |
|---|---|
| Legal name, billing address, ERP customer ID, credit limit | ERP |
| Account executive, strategic account flag, success tier | Salesforce |
One record; the truth is distributed. That’s normal. “System of record = Salesforce” doesn’t describe it. An authority model does.
Created, Edited, Referenced, and How Fast?
Section titled “Created, Edited, Referenced, and How Fast?”When I teach master data, I keep coming back to the same questions for every important piece of data: where is it created, where is it edited, where is it referenced, and what’s its latency of change? They expose the architecture fast. (You met the first three in chapter 4, sorting the kinds of data; here’s where they do their real work.)
Take an asset. A customer orders three bicycles. Salesforce has the opportunity and its line items, and the order goes to the ERP. The ERP fulfills it, and that’s where the assets are created: three bicycles, three serial numbers, sent back to Salesforce. Months later the customer calls about one of them, and support references the asset in a case. Now someone needs to correct an attribute. Which ones may Salesforce edit, and which belong to the ERP that created them? And when the ERP changes one, how fast does Salesforce need to know? One asset, four questions, and the answers aren’t the same for every field.
Say the legal name is created in the ERP and referenced in Salesforce, and a rep notices it’s wrong. Should they fix it in Salesforce? If the ERP owns the field, changing the copy fixes nothing. At best the next sync overwrites it; at worst the two systems now disagree and nobody knows which to trust. If the business wants the rep to start the correction, that’s different: Salesforce provides the experience, sends a request to the ERP, the ERP makes or approves the change, and the authoritative value comes back. That’s a very different architecture from letting Salesforce edit the field on its own.
Latency is part of truth too. The ERP changes a customer’s credit status at 10 a.m.; Salesforce syncs it nightly; at 3 p.m. a rep looks at Salesforce. Is the value wrong? It’s stale. If the value changes once a year and a day’s delay costs nothing, nightly is fine. If it decides whether you accept a million-dollar order today, it isn’t. Authority says where truth comes from; latency says how fast others must learn it changed. Two separate decisions.
System of Record, Engagement, Reference
Section titled “System of Record, Engagement, Reference”Chapter 4’s vocabulary helps here. A system of record maintains the authoritative version. A system of engagement is where people work with it. A system of reference supplies data another system uses but doesn’t own. Salesforce can be the system of engagement for the customer relationship while the ERP stays the system of record for its legal and financial attributes. That isn’t a weakness in the architecture; it is the architecture. The mistake is pretending one system must own everything so the diagram looks simpler.
The Hybrid Golden Record
Section titled “The Hybrid Golden Record”That changes what “golden record” means. Chapter 5 introduced the idea while keeping bad data out; here it’s the heart of the design. People picture one magical record with every field mastered in one place. Sometimes that’s the design. On Salesforce, more often I see a hybrid: part of the account mastered elsewhere and copied in (legal name, ERP customer number, billing address, credit status), and part that exists only because Salesforce needs it (account executive, opportunity strategy, success tier, relationship notes). The ERP fields come in so people can use them. The Salesforce fields never go back, because the ERP doesn’t care about them. Perfectly reasonable, as long as everyone knows which is which.
Make Authority Visible
Section titled “Make Authority Visible”So I make external authority obvious in the schema. If SAP controls a field, it gets a prefix: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. It’s the same idea as chapter 4’s erp_ prefix. Use the system’s name when that authority is specific and stable, and a generic prefix when the meaning matters more than today’s vendor. The point is that six months later, someone reading the model can see: this isn’t just another Salesforce field; another system owns this value. Don’t make people rediscover authority by reverse-engineering integrations.
Build an Authority Map
Section titled “Build an Authority Map”For important master data, I want an authority map: for each key attribute, who creates it, who owns the business decision, which system is authoritative, and who or what may change it. Four different questions:
| Attribute | Created by | Business owner | Authoritative system | May change it |
|---|---|---|---|---|
| Legal name | Finance | Finance | ERP | The finance process |
| Credit limit | Finance | Finance | ERP | The credit team |
| Account executive | Sales operations | Sales | Salesforce | Sales management |
| Support tier | Service operations | Service | Salesforce | Service management |
| Consent | The customer | Privacy | Consent platform | The customer, an approved process |
Notice that business owner and authoritative system aren’t the same thing. A system doesn’t own policy; people do. The system stores and enforces the result. That’s chapter 5 again: owners set policy; architects enforce it.
One customer. Many attributes. One authority for each.
Authority Changes Over the Lifecycle
Section titled “Authority Changes Over the Lifecycle”A rep meets a prospect the ERP has never heard of and creates the account in Salesforce. At that point Salesforce is authoritative for the name, address, contacts and qualification. The prospect becomes a customer; the ERP creates the official customer and assigns the customer number, legal name, billing address and credit. Authority moved. Salesforce wasn’t wrong before; the lifecycle changed. It’s chapter 5’s provisional-to-governed pattern: before conversion, Salesforce owns the prospect; after, the ERP owns the governed attributes, and Salesforce keeps owning its own. So “which system owns the account?” is a weak question. Ask: which system owns this attribute, at this point in the lifecycle?
A Copy Isn’t Authority
Section titled “A Copy Isn’t Authority”We copy ERP data into Salesforce because people need it constantly. That makes Salesforce a convenient local copy, not the master, and the architecture should behave accordingly: read-only for users, refreshed by the integration, labeled with its source, changed only through a request, checked by reconciliation when the copy drifts. The copy is useful. The authority hasn’t moved.
Trust Needs More Than a Value
Section titled “Trust Needs More Than a Value”“Billing address: 123 Main Street.” Should you trust it? I want trust signals: where it came from, when it was last confirmed, which system supplied it, and who or what last changed it: a person, an integration, an agent? Now the ERP says 123 Main Street, Salesforce says 125, and a partner file says “123 Main St., Suite 200.” Which is right? Don’t answer “use the most recent one.” Maybe. But “most recent” is itself a rule that assumes whoever changed it last deserves to win. That might be true, or terrible. Module 3 takes this on. Trust comes from authority and provenance, not from finding a field that’s filled in.
Steve Trucking: Whose Truth Is It?
Section titled “Steve Trucking: Whose Truth Is It?”A Retail Partner sends a delivery, and several truths hide in that one transaction. The partner’s order reference is the partner’s; Steve Trucking keeps it to match updates, but doesn’t become its master. The delivery status (arrived, delivered, installed, an exception) is Steve Trucking’s; the partner receives it, but receiving a status doesn’t make the partner authoritative for what happened on the truck. And the Recipient is the partner’s customer. The partner supplies the name, address, phone and delivery notes because Steve Trucking needs them to deliver. That doesn’t make Steve Trucking the master of that person’s identity, and that distinction decides the Recipient design at the checkpoint.
One delivery, two authorities.
Where data lives and who owns its truth are different questions. Salesforce can hold the ERP customer number without owning it; Snowflake can hold delivery status without being its operational master; a customer data platform can unify identities without owning every attribute. An agent can read all three, and that certainly doesn’t let the agent decide which is true.
Beyond the exam: what AI changes. Agents turn attribute authority into an execution rule. A person sees a wrong billing address and knows “that comes from SAP; I shouldn’t change it here.” An agent told to “update the customer’s billing address” won’t know unless we design for it. It needs the same authority map the architect has: access to a field doesn’t make that field the right place to write.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Which system is authoritative for each important attribute, rather than one system for a whole record.
- Where each attribute is created, edited and referenced, and how fast its changes must travel.
- Who sets the policy for each attribute, and which people, integrations or agents may change it.
- How external authority shows in the model: naming prefixes, permissions, integration behavior.
- How authority shifts over the lifecycle, such as a prospect becoming an ERP-governed customer.
A single source of truth doesn’t mean one org, one ERP, one MDM platform or one giant record. It means that for each piece of governed information, the architecture can say where the authoritative value is, and every other system knows how to behave because of it. That’s not a single source of truth. It’s an architecture of truth.
Explore
Section titled “Explore”- Salesforce Architects, Data 360 Architecture (opens in a new tab), checked 2026-10-14.