CRM as the System of Record: What It Can and Cannot Prove

A CRM system of record is the authoritative operational source for defined customer, lead, account, opportunity, and sales-process facts. It should not automatically be treated as the authority for every customer fact or every revenue number stored inside it.
That distinction matters more than where the data appears.

Key Takeaways

• A CRM system of record should be authoritative for defined customer, account, lead, opportunity, lifecycle, and sales-process facts – not every customer or revenue fact stored inside the CRM.
• Data authority should follow the fact. CRM may own opportunity stage and account ownership, while billing, finance, marketing, product, support, or analytics systems remain authoritative for the data they originate and govern.
• Trustworthy CRM data requires clear field ownership, controlled write access, source provenance, audit history, stable definitions, and sufficient accuracy, completeness, consistency, and freshness for the decision being made.
• CRM reporting can describe governed operational states and preserve evidence for revenue and attribution analysis. CRM alone cannot prove payment settlement, recognized revenue, the complete customer journey, or that a marketing interaction caused a sale.

A CRM field may be created inside the CRM, copied from another system, enriched by a third party, calculated from other fields, or inferred by a model. Those values can sit beside each other on the same record while carrying very different levels of authority.

For practical purposes, separate four states:

• Recorded: the value exists in the CRM.
• Authoritative: the CRM is designated to own that fact.
• Verified: there is enough evidence to support the fact.
• Derived: the value was calculated or inferred from other data.

IBM defines a system of record as an authoritative source of business data and notes that organizations can use different systems of record for different domains. CRM is one example alongside ERP, HCM, and other operational systems.

The important question is therefore not, “Can we trust the CRM?”

It is: Which CRM facts can we trust, for which decisions, and where does that authority end?

Start here

• Executive or revenue leader: Which CRM numbers can I safely treat as business facts?
• RevOps or CRM owner: Which system owns each field and event?
• Finance or analytics: Which CRM records need another source before they support a revenue conclusion?

The rest of the decision follows from one principle: a CRM earns authority fact by fact, not simply by becoming the place where everyone looks.

CRM system of record vs source of truth

A CRM can be the system of record for customer and sales data without being the organization’s single source of truth. The concepts overlap, but they solve different problems.

A system of record answers: Which system owns this fact?

A source of truth answers a broader question: Which combination of authoritative facts gives us the best answer to this business question?

IBM makes the distinction explicit. A system of record owns authoritative data within a business domain or process, while a source of truth can aggregate and harmonize data from several systems of record.

What “system of record” means for CRM

A system of record is the designated authority for a defined class of information. Other systems may read or copy that information, but they do not automatically become authoritative for it.

For CRM, that can include facts such as account ownership, opportunity stage, lead status, lifecycle position, or the recorded relationship between a contact and an account.

The scope must stay precise.

“CRM owns customer data” is too broad to govern a real data architecture. One customer may have a sales owner in CRM, invoices in an ERP, payment status in a billing platform, usage history in a product system, and service history in a support platform.

Each fact can have a different system of record.

System of record vs source of truth

A system of record owns a fact within its domain. A source of truth reconciles facts across domains.

Suppose CRM records an opportunity as Closed Won. Billing records an invoice. A payment system records cash received. Finance records recognized revenue.

Those records do not have to match.

They describe different events.

A source-of-truth layer may combine them to answer, “What commercial value did this customer actually produce?” But it depends on the original systems that own each underlying fact.

This creates an important boundary:

Moving data into CRM improves access. It does not automatically transfer authority.

System of record vs single source of truth

A single source of truth is usually a unified, consistent view of information. It does not require one application to create every fact.

Salesforce describes CRM as a system for managing customer and prospect interactions and notes that CRM tools can unify customer and company data from multiple sources.

A CRM can therefore give teams one customer view while still containing:

• CRM-owned facts;
• synchronized facts owned elsewhere;
• calculated values;
• analytical outputs.

The useful test is not whether a value appears in CRM.

It is whether the organization can answer three questions about it:

Where did it originate? Who owns it? Which source wins if systems disagree?

System of record vs system of action or engagement

A system of record describes an authoritative state. A system of action uses information to determine or execute what should happen next.

A CRM may correctly show that a qualified lead has had no sales contact for four days. That is a record.

Assigning a salesperson, triggering follow-up, escalating the delay, or changing the workflow is action.

Keeping these functions separate prevents a different type of confusion: an accurate CRM record does not prove the surrounding process works well.

The broader operating model for ownership, stages, automation, handoffs, and exceptions belongs within Marketing Automation and CRM. Here, the narrower issue is authority: which facts should CRM own in the first place?

Which customer and revenue facts the CRM should own

CRM data ownership should be defined at the level where disagreement occurs: the data domain, field, relationship, state, or event.

Salesforce describes core CRM functions as storing customer and prospect information, tracking interactions, identifying sales opportunities, and organizing records for use across the business.

Those functions show where CRM ownership often makes sense. They do not make every field equally authoritative.

Customer, account and lead relationship state

CRM is often the natural authority for commercial relationship state.

That can include:

• contact-to-account relationships;
• lead ownership;
• account ownership;
• lifecycle stage;
• customer or prospect status.

The CRM may authoritatively state, for example, that Contact A belongs to Account B in the sales model.

It may not prove that every identity field on Contact A is correct.

An email address, phone number, job title, or company size may have come from the contact, an enrichment provider, an import, or another system. The CRM can store those values without owning the underlying truth.

The rule is simple: relationship authority and identity verification are not the same thing.

Opportunity, pipeline and sales-process state

Opportunity data is one of the strongest candidates for CRM authority.

The CRM can often own:

• opportunity creation;
• opportunity owner;
• stage;
• status;
• expected close date;
• recorded deal amount;
• Closed Won or Closed Lost state;
• timestamped lifecycle transitions.

These are sales-process facts.

They are not automatically financial facts.

A CRM record showing a $100,000 Closed Won opportunity can establish that the sales process recorded $100,000 as won. It does not by itself establish that $100,000 was invoiced, collected, or recognized as revenue.

That difference becomes important as soon as CRM pipeline data reaches financial reporting.

Activity and communication records

CRM may own the fact that an activity was recorded without owning the original communication.

For example, CRM can record:

• an email event;
• a completed call;
• a meeting;
• a sales note.

The original email may remain in the email platform. The call recording may live in a call-tracking system. The calendar platform may own the original meeting event.

This changes what the evidence supports.

“The CRM records a call on August 12” is a CRM-level claim.

“The customer agreed to a specific commercial term on August 12” requires evidence from the conversation itself.

The more specific the claim becomes, the more important the original source becomes.

Imported, enriched and calculated fields

Imported and calculated values create the greatest risk of confusing visibility with authority.

A useful CRM data model distinguishes:

1. original CRM facts;
2. synchronized copies;
3. enriched values;
4. calculated values;
5. inferred values.

The distinction becomes easier to apply through an ownership matrix:

Data domain	CRM role	Typical authoritative system	CRM can prove	CRM cannot prove by itself
Contact/account relationship	Primary record	CRM	Recorded relationship and owner	Independent identity accuracy
Sales opportunity	Primary record	CRM	Stage, owner, status, recorded amount	Payment or recognized revenue
Marketing interaction	Reference or synchronized	Marketing, analytics, or ad system	Data received and associated with a CRM record	Complete original interaction history
Invoice or payment	Reference	Billing, ERP, payment, or finance system	Financial value copied into CRM	Settlement or accounting treatment
Support event	Reference or shared	Support platform	Synchronized service state	Complete original support context
Lead score or forecast	Derived	Rule or model owner	Current model output	That the predicted outcome will happen

The pattern is more useful than any vendor-specific rule:

CRM should own facts closest to the business process it governs. Other systems should keep authority over facts they originate and control.

When another source system should outrank the CRM

Another system should outrank CRM when that system is the legitimate origin and authority for the fact being disputed.

This can feel counterintuitive when CRM is the interface leadership uses most often. But the most visible system is not always the authoritative one.

Marketing and acquisition systems

Marketing, advertising, analytics, and call-tracking systems often originate acquisition events before CRM sees them.

Examples include:

• ad impressions and clicks;
• campaign interactions;
• website events;
• form-session data;
• tracking identifiers;
• call-source events.

CRM can preserve these signals and connect them to a lead, contact, opportunity, or customer.

That relationship is valuable. It does not make CRM the original authority for the marketing event.

If the business needs to verify whether an ad click occurred or which tracking identifier was created, the originating measurement system remains relevant.

Finance, billing and payment systems

Financial facts require particularly clear boundaries.

Consider four numbers:

• CRM deal amount;
• invoiced amount;
• cash collected;
• recognized revenue.

They may all be valid while being different.

The error comes from treating them as interchangeable versions of “revenue”.

CRM may own the commercial amount attached to an opportunity. Billing may own the invoice. A payment system may own settlement status. Finance may own recognized revenue.

For an executive report, the correct source depends on the claim.

If the question is “What did sales close?”, CRM may be sufficient.

If the question is “What cash arrived?”, it is not.

Product, service and support systems

Customer reality continues outside sales.

Product usage, subscription state, fulfillment, service delivery, and support events often originate in dedicated systems.

CRM may synchronize those values so teams can see a fuller customer picture. That improves usability without changing the source of authority.

If CRM says a customer is active while the subscription platform says the subscription ended, the organization needs a predetermined rule for which system wins.

Without that rule, every disagreement becomes manual interpretation.

Data warehouse, BI and MDM layers

A CRM data warehouse, BI environment, or master data management layer can reconcile information across systems.

IBM describes MDM as an enterprise approach that can combine information from several systems of record into a validated or “golden” record.

That becomes useful when leadership asks cross-domain questions such as:

• Which acquisition sources produce paying customers?
• Which opportunities become recognized revenue?
• Which accounts generate strong sales but poor retention?

The analytical layer can connect the domains. It does not erase the authority of the systems underneath them.

The governing rule

Assign authority per fact or data domain, not per software platform.

CRM can own opportunity stage.

Billing can own payment status.

A product system can own usage.

Finance can own recognized revenue.

A marketing system can own an original campaign event.

This architecture allows teams to work from a unified view without pretending that one database created every fact inside it.

Once authority is separated this way, the next question becomes sharper: what does an authoritative CRM record actually prove?

What the CRM can prove – and what it cannot

An authoritative CRM record can prove a defined CRM state. It cannot automatically prove the broader business reality surrounding that state.

This is where many reporting problems start. A narrow record is turned into a broader claim without adding the evidence needed to support it.

What an authoritative CRM record can prove

Where CRM data governance and audit history are sound, the system can support claims about its own governed records.

It may establish that:

• a value was recorded;
• a person or team owned a record;
• an opportunity occupied a defined stage;
• a lifecycle transition was recorded;
• a timestamp exists;
• two records were associated;
• an auditable field change occurred.

Precision in wording matters.

“The CRM recorded the opportunity as Closed Won on June 10” is a supportable CRM claim.

“The customer generated revenue on June 10” adds a financial claim that may require another source.

What “stored in the CRM” does not prove

A value being stored in CRM does not prove its origin, accuracy, completeness, or authority.

The value could have come from:

• manual entry;
• synchronization;
• enrichment;
• import;
• workflow automation;
• a calculation.

It could also have been overwritten after it was first recorded.

A populated field therefore answers one question:

What value is stored here?

An authoritative field must answer another:

Why should this value win when evidence conflicts?

That is why provenance, field ownership, and auditability matter more than simple record completeness. The consolidation strategy for this keeper applies that distinction between populated records and governed, traceable CRM truth.

What CRM cannot prove by itself

CRM usually cannot prove the complete customer journey, causal marketing impact, payment settlement, full conversation context, or facts that were never captured.

The proof boundary can be stated directly:

Claim type	Is CRM alone sufficient?	Additional authority typically required
Current opportunity owner	Often	CRM governance
Recorded lifecycle stage	Often	Defined stage rules
Advertising click occurred	Usually not	Advertising or tracking source
Customer paid an invoice	Usually not	Billing or payment system
Revenue was recognized	Usually not	Finance or accounting system
Marketing caused the sale	No	Attribution plus causal evidence
Customer made a specific statement	Usually not	Original email, call, or transcript
Lead score predicts the outcome	No	Validated model and outcome evidence

This produces a useful decision rule:

The broader the claim, the more likely CRM evidence must be combined with another authoritative source.

That does not reduce the value of CRM. It prevents CRM data from being asked to prove something outside its domain.

Governance and change control for authoritative CRM data

CRM authority depends on control. A field cannot remain a reliable system-of-record fact if its definition, writers, and override rules are unclear.

A surprisingly large governance problem can therefore begin with something as simple as two integrations being allowed to update the same field.

Assign authority by data domain and field

“RevOps owns CRM” describes platform responsibility. It does not fully define CRM data ownership.

Governance needs to identify who or what controls important facts.

For example:

• who defines opportunity stages;
• who owns lifecycle definitions;
• which system sets payment status;
• who approves changes to calculated fields;
• which system resolves an identity conflict.

Authority becomes useful when it reaches the level where disagreement can occur.

Define write authority and precedence

An important CRM field may be changed by a user, integration, import, automation, enrichment provider, or connected application.

If several writers are permitted, the system needs precedence rules.

Otherwise the latest update becomes the accidental truth.

Good CRM data governance therefore answers two separate questions:

Who is allowed to write this value?

Whose value wins when legitimate writers disagree?

That turns integration logic into governed business logic.

Preserve change history and provenance

Important CRM records should make material changes explainable.

For a disputed value, teams should be able to determine:

• who changed it;
• which system changed it;
• when it changed;
• what the previous value was;
• where the new value came from.

Provenance converts a disagreement from opinion into an investigation.

Without it, people often create their own evidence systems: spreadsheets, screenshots, exports, private notes, or manual reporting layers.

Source visibility, change history, auditability, automation overrides, and shadow systems are core signals of whether CRM authority can be defended.

Control semantic changes

A database can remain technically accurate while the meaning of its data changes.

Suppose “Qualified Lead” means one thing in Q1 and another in Q3. The same field name now represents two business definitions.

Historical comparisons become weaker even if every record is intact.

Change control should therefore cover:

• lifecycle definitions;
• opportunity stages;
• status meanings;
• calculation logic.

Values require governance. Definitions do too.

Resolve disagreements between systems

A mature data model decides how disagreements are resolved before they happen.

If CRM owns opportunity stage, its stage should win that dispute.

If billing owns payment status, billing should win the payment dispute.

If a report combines both, the reporting layer should preserve the separate definitions and reconcile them under documented rules.

• This avoids three weak alternatives:
• last write wins;
• the most senior person wins;
• whichever dashboard someone trusts wins.

Authority only becomes useful when conflicts have a predictable resolution.

What makes CRM data trustworthy

Trustworthy CRM data is accurate enough for its purpose, sufficiently complete, current enough for the decision, consistent with related records, and traceable to its origin.

IBM describes data quality using dimensions that include accuracy, completeness, validity, consistency, timeliness, and fitness for purpose. It also links system-of-record authority to data integrity, validation, synchronization, and governance.

The important distinction is that clean data and trustworthy data are not identical.

Accuracy and validity

Accuracy asks whether a value represents the intended fact.

Validity asks whether it follows the defined rules for that field.

An email address can have a valid format and still belong to the wrong person.

An opportunity stage can be a valid CRM option and still be the wrong stage for the deal.

CRM data validation helps reject impossible or malformed values. It cannot replace business judgment about whether the value reflects reality.

Completeness

A dataset can contain only correct records and still create a misleading business conclusion if important records are missing.

A pipeline report may be accurate for every opportunity entered into CRM while excluding deals managed in spreadsheets or external systems.

The records are correct.

The pipeline view is incomplete.

Completeness must therefore be tested against the decision the data is supposed to support, not only against required-field completion.

Freshness and timeliness

Some facts lose operational value quickly.

An account owner recorded six months ago may be historically accurate and useless for today’s routing decision.

A stale pipeline stage may distort a forecast even if it was correct when entered.

CRM data quality therefore depends partly on whether a field is current enough for its purpose.

Consistency across related records

Related records should not contradict each other without a known reason.

A contact marked Customer while the associated account remains Prospect may be valid under a particular data model. It may also reveal that two workflows update related objects differently.

Consistency checks help expose these conflicts.

They become especially important as automation spreads updates across contacts, companies, deals, and lifecycle objects.

Traceability to the originating source

Copied data should remain traceable to where it came from.

A payment status is easier to trust when CRM can identify the billing system that supplied it.

A campaign field is more useful when the original acquisition identifier remains available.

A derived metric is easier to interpret when its inputs and logic can be found.

Traceability prevents copied values from appearing more authoritative than the systems that produced them.

Warning signs that CRM authority has failed

CRM authority is weakening when:

• teams maintain shadow spreadsheets for “the real numbers”;
• departments use different definitions for the same lifecycle stage;
• reports need repeated manual reconciliation;
• automation changes cannot be explained;
• users regularly dispute which number is correct;
• teams export CRM data before trusting it.

These symptoms are not all duplicate-record or contact-hygiene problems.

Detailed duplicate remediation belongs to CRM data-quality work. Object and contact schema design belongs to the data-model layer.

The system-of-record question stays narrower:

Can the organization identify which version of an important fact should win and explain why?

If the answer is no, the next dashboard will inherit the same uncertainty.

Reporting and attribution limitations

CRM reporting is most reliable when it reports facts the CRM itself governs. Confidence becomes more conditional as reports combine synchronized data, financial data, attribution data, and model outputs.

A dashboard can therefore be mathematically precise while still answering the wrong business question.

Operational CRM reporting

CRM is usually well suited to reporting its own operational states.

Examples include:

• pipeline stage;
• lifecycle status;
• owner;
• opportunity movement;
• recorded sales activity.

When the underlying fields are CRM-owned and properly governed, reporting stays close to the authoritative source.

That is the strongest form of CRM reporting.

Cross-system reporting

Once a report combines CRM with advertising, analytics, product, support, billing, or finance data, CRM becomes one input in a wider measurement architecture.

This is often necessary.

Important commercial questions rarely belong to one system.

BiViSee’s Marketing Measurement and Attribution framework treats marketing, CRM, sales, and revenue data as connected sources that need aligned definitions, identifiers, stages, and reporting rules before they can support the same decision.

Cross-system reporting should preserve those source boundaries rather than flattening every value into generic “customer data”.

Revenue reporting

Revenue reporting needs especially precise definitions.

A CRM deal amount may describe expected commercial value.

A Closed Won amount may represent sales-booked value.

An invoice represents an amount billed.

A payment record represents money collected.

Recognized revenue belongs to the relevant financial reporting rules and systems.

Different numbers do not automatically indicate bad data. They may describe different stages of value.

BiViSee’s analysis of attribution-revenue mismatch makes the same distinction between marketing-attributed outcomes and revenue recognized in financial systems.

The decision rule is direct:

Before asking whether a revenue number is correct, define which revenue event the number represents.

Marketing attribution

CRM is an important part of marketing attribution because it can preserve source fields, campaign relationships, click IDs, lifecycle states, opportunities, and revenue associations.

That creates continuity between acquisition and commercial outcomes.

It does not prove causation.

An attribution model assigns credit according to observed touchpoints and model rules. The existence of a CRM source field may establish an association. It cannot establish that the marketing touchpoint caused the purchase.

BiViSee covers that distinction in Why Attribution Assigns Credit but Can’t Prove Cause.

CRM can preserve attribution evidence.

It cannot turn association into causal proof.

Derived metrics should remain visibly derived

Forecast probability, lead score, attribution credit, propensity, estimated lifetime value, and calculated lifecycle metrics are outputs of rules or models.

They are not observed facts.

That distinction should remain visible in reporting.

If a forecast changes, leadership should be able to determine whether:

• the opportunity changed;
• an input field changed;
• the forecast model changed.

The same applies to lead scores and attribution credit.

Derived metrics can be highly useful. Their authority comes from the quality of their inputs and methodology, not from being displayed beside CRM facts.

This is where the CRM truth boundary connects to analytics: CRM should preserve governed inputs, while detailed attribution methodology and data-lineage implementation belong in the measurement layer.

Decision framework: when CRM is sufficient as the system of record

CRM is sufficient as the system of record when the fact belongs to its defined operational domain, its meaning is stable, write authority is controlled, changes are traceable, and connected systems know when to defer to it.

The goal is not to make CRM authoritative for everything.

It is to make its authority unambiguous where it matters.

CRM can be authoritative when

CRM can reasonably act as the authoritative system when:

• the fact belongs to a CRM-managed domain;
• its definition is explicit;
• the source of the value is known;
• permitted writers are controlled;
• competing writes have precedence rules;
• material changes are traceable;
• connected systems defer to CRM for that fact.

Under those conditions, CRM becomes more than shared storage.

It becomes dependable operational evidence.

CRM should be only one of several systems of record when

Most customer relationships cross several legitimate data domains.

Marketing creates acquisition events.

CRM manages commercial relationships.

Billing manages invoices and payments.

Product systems manage usage.

Support systems manage service interactions.

Finance manages financial reporting.

Several systems of record can therefore be the correct architecture.

The problem is not having multiple authorities.

The problem is failing to define their boundaries.

A company can still provide employees with one usable customer view while preserving distinct authoritative systems underneath it.

Do not call CRM the “single source of truth” until leadership can answer

Before leadership calls CRM the single source of truth, it should be able to answer seven questions:

1. Which facts does CRM actually own?
2. Which values are copied into CRM?
3. Which values are calculated or inferred?
4. Which source wins when systems disagree?
5. Can important changes be traced?
6. Which reports require another authoritative source?
7. Which claims cannot be proven from CRM alone?

Those questions form the final CRM authority test:

• Original? Where did the fact originate?
• Owned? Which system has authority over it?
• Controlled? Who or what may change it?
• Traceable? Can its source and important changes be reconstructed?
• Current? Is it recent enough for the decision?
• Reconciled where necessary? Have legitimate conflicts with other systems been resolved?
• Sufficient for the claim being made? Does the evidence prove the conclusion, or only one part of it?

That final question is the boundary that matters most.

A CRM system of record does not need to contain every truth about a customer. It needs to make clear which facts it owns, why those facts deserve authority, and when another system must provide the evidence instead.

Once that is explicit, leadership no longer has to ask which database contains the answer.

It can ask the more useful question:

Which system has the authority to prove it?

Scientific context and sources

The sources below combine primary industry documentation with academic research supporting the system-of-record, CRM data ownership, data-quality, provenance, governance, master-data, and attribution principles used on this page. The primary sources establish current definitions and platform context; the academic research provides the underlying information-management and measurement foundations.

• System of record, data authority, and data quality
  What Is a System of Record? – IBM
  Defines a system of record as an authoritative source of business data and explains that different systems can serve as systems of record for different business domains. The resource also connects system-of-record architecture with data integrity, validation, synchronization, governance, master data management, and dimensions of data quality such as accuracy, completeness, validity, consistency, and timeliness.
  https://www.ibm.com/think/topics/system-of-record
• System of record vs source of truth
  System of Record vs. Source of Truth: What’s the Difference? – IBM
  Distinguishes domain-level data authority from cross-domain reconciliation. A system of record owns authoritative data within a specific business process or domain, while a source of truth can combine and harmonize data from several systems. This distinction supports the article’s argument that CRM can be authoritative for selected facts without becoming the authority for every customer or revenue fact.
  https://www.ibm.com/think/topics/system-of-record-vs-source-of-truth
• CRM as an operational customer-data system
  What Is CRM? – Salesforce
  Describes CRM as a system for managing relationships and interactions with customers and prospects. It also explains core CRM functions such as storing customer information, tracking interactions, identifying sales opportunities, and bringing together data from multiple sources. This provides practical context for deciding which customer and sales-process facts CRM should own.
  https://www.salesforce.com/crm/what-is-crm/
• Data quality extends beyond accuracy
  Beyond Accuracy: What Data Quality Means to Data Consumers – Richard Y. Wang and Diane M. Strong – Journal of Management Information Systems
  Foundational information-systems research showing that useful data quality cannot be reduced to accuracy alone. The study develops a broader framework based on how data consumers assess information, supporting the distinction in this page between accuracy, completeness, timeliness, consistency, and fitness for a particular decision.
  https://doi.org/10.1080/07421222.1996.11518099
• Data provenance and the origin of a record
  Why and Where: A Characterization of Data Provenance – Peter Buneman, Sanjeev Khanna, and Wang-Chiew Tan – International Conference on Database Theory
  A foundational database study on data provenance: where a piece of data came from and the process through which it reached a database. It provides the technical foundation for treating source, transformation history, and traceability as separate from the fact that a value is currently stored in a CRM.
  https://doi.org/10.1007/3-540-44503-X_20
• Data governance, authority, and control
  Data Governance: A Conceptual Framework, Structured Review, and Research Agenda – Rene Abraham, Johannes Schneider, and Jan vom Brocke – International Journal of Information Management
  A structured review of 145 research papers and practitioner publications that frames data governance around authority and control over organizational data. It supports the need to define governance mechanisms, data scope, domain scope, decision rights, and accountability rather than assuming that the application containing a field automatically owns that field.
  https://doi.org/10.1016/j.ijinfomgt.2019.07.008
• Master-data architecture across multiple systems and owners
  How to Design the Master Data Architecture: Findings from a Case Study at Bosch – Boris Otto – International Journal of Information Management
  Examines master-data architecture as both an organizational and technical design problem. The Bosch case shows why enterprise data architecture must account for different data classes, stakeholders, systems, and governance requirements rather than forcing all authoritative information into one application.
  https://doi.org/10.1016/j.ijinfomgt.2011.11.018
• Attribution evidence does not automatically establish causation
  A Comparison of Approaches to Advertising Measurement: Evidence from Big Field Experiments at Facebook – Brett R. Gordon, Florian Zettelmeyer, Neha Bhargava, and Dan Chapsky – Marketing Science
  Compares observational advertising measurement with randomized experiments across 15 large U.S. advertising experiments. The observational methods often failed to recover the causal effects measured experimentally, providing direct research support for the distinction between CRM-recorded attribution evidence, observed association, and causal marketing impact.
  https://doi.org/10.1287/mksc.2018.1135

Questions You Might Ponder