Master Data Management with Salesforce: The Myths vs Reality

What MDM Actually Is

Master Data Management (MDM) is the discipline of creating and maintaining a single, authoritative, reliable version of critical business data — customer records, product records, supplier records — across an enterprise's systems. True MDM means that when SAP, Salesforce, the e-commerce platform, and the customer service system all reference "Acme Corporation," they are all referencing the same golden record with consistent, authoritative attributes. This is significantly harder to achieve than most MDM project scopes acknowledge.

The MDM myth in Salesforce projects is that implementing Salesforce's duplicate management features constitutes implementing MDM. Salesforce's duplicate management (matching rules and duplicate rules) prevents obvious duplicates during data entry and identifies existing duplicates in the Salesforce org. This is important data hygiene, but it is not MDM — it only governs data within Salesforce, not across the enterprise landscape of systems that all have their own customer records.

True enterprise MDM requires: a canonical data model that all systems agree on, a golden record master that is authoritative, a data stewardship process for resolving conflicts and ambiguities, synchronisation mechanisms that propagate master data from the MDM system to all consuming systems, and governance processes that prevent systems from creating divergent copies. Most Salesforce implementations have pieces of this but not the whole picture.

MDM Implementation Styles

Registry-style MDM maintains a central registry of entity identifiers without storing master attributes. Each system keeps its own record; the registry maps the IDs across systems (Salesforce Account ID 001xxx = SAP BP 10045 = Oracle Party ID 55123). The registry enables cross-system identity resolution without requiring all systems to synchronise all attributes. This is the lowest-disruption MDM style but provides limited data quality improvement — each system still maintains its own (potentially inconsistent) attributes.

Consolidation-style MDM extracts data from all systems into a central MDM hub that creates a golden record, but the source systems are not updated from the hub — they continue operating independently. The hub provides a read-only consolidated view for analytics and reporting. This style is common and provides significant analytical value but does not improve operational data quality in the source systems.

Coexistence-style MDM maintains master attributes in the hub and synchronises them back to source systems. When the MDM hub identifies that Salesforce and SAP have different addresses for Acme Corporation, the hub applies the golden record address to both systems. This is the first style that actually improves operational data quality but requires source systems to accept data writes from the hub — a political and technical challenge.

Centralised-style MDM makes the MDM hub the authoritative system for all master data creation and updates. Systems no longer create or update customer records independently — they submit requests to the hub, which validates, deduplicates, and distributes the approved record. This is the highest-governance, highest-impact style and the hardest to implement because it requires all systems to relinquish their autonomy over master data creation.

Salesforce as System of Record — What It Actually Means

When organisations declare "Salesforce is our system of record for customer data," they typically mean Salesforce is the most complete and most current source of customer information for their sales and service teams. This is true for a narrow definition of "system of record" — Salesforce is authoritative for the customer data that sales and service teams manage. But it is not automatically the case that SAP, billing systems, and the website treat Salesforce as the authority for customer data they manage in their own domains.

The Account object in Salesforce is a reasonable domain for customer master data if Salesforce is truly the first system updated when customer attributes change. The test: when a customer calls to update their billing address, does the call center representative update it in Salesforce first (with sync to SAP) or in SAP first (with sync to Salesforce)? The system updated first is the authoritative system. If the answer varies by situation or by team, there is no true system of record — there are two competing systems of record in conflict.

Making Salesforce the genuine system of record requires more than an architecture decision — it requires changing business processes. The billing address change process must route through Salesforce. The new customer onboarding process must start in Salesforce. The customer merge process (when two duplicate customers are identified) must be governed by Salesforce stewards. Technology implements the decisions; the decisions are organisational.

// Querying potential duplicate accounts for stewardship review
SELECT Id, Name, BillingCity, BillingCountry, Phone,
       SAP_Customer_ID__c, External_ID__c,
       CreatedDate, LastModifiedDate
FROM Account
WHERE SAP_Customer_ID__c != null
  AND Id IN (
    SELECT AccountId FROM DuplicateRecordItem
    WHERE DuplicateRecordSetId IN (
      SELECT Id FROM DuplicateRecordSet
      WHERE DuplicateRule.DeveloperName = 'Account_MDM_Rule'
    )
  )
ORDER BY Name, CreatedDate

Golden Record Management Patterns

A golden record is the authoritative version of a master data entity — the one record that all systems should consider correct. In Salesforce, the golden Account record for Acme Corporation should have the verified billing address, the correct legal entity name, the current primary contact, and the canonical customer ID that all systems reference. Maintaining golden records requires three things: a matching process to identify duplicates, a merge process to resolve duplicates into a single golden record, and a synchronisation process to propagate the golden record attributes to all consuming systems.

Salesforce's built-in duplicate management uses configurable matching rules (field-weighted fuzzy matching on name, address, email, phone) to identify potential duplicates at data entry time and as a batch scan of existing records. For production-scale MDM, the standard duplicate management is often insufficient — it lacks the probabilistic matching across cross-system identifiers that enterprise MDM requires. Organisations implementing serious MDM typically supplement with dedicated MDM tools (Informatica MDM, Reltio, Semarchy) that integrate with Salesforce as a consuming system.

When duplicate Accounts are identified and merged in Salesforce, the merge operation combines the two records into one, selecting field values from either source record and preserving all child records (Contacts, Opportunities, Cases) on the surviving record. The loser Account ID is permanently deleted. Any external system that holds the loser Account ID as a foreign key must be notified of the ID change — this is the integration coordination challenge that makes cross-system MDM complex.

Data Governance: The Non-Technical Requirement

Data governance for MDM requires three organisational components that technology cannot substitute: data ownership, data stewardship, and data policies. Data ownership assigns accountability for master data quality to a specific business role — the VP of Sales owns the quality of Account master data, with that ownership embedded in their performance objectives. Without ownership, nobody is accountable when data quality degrades.

Data stewards are operational resources who manage the day-to-day data quality work: investigating potential duplicates, merging records, resolving conflicting data between systems, and approving new customer records created by non-standard channels. In practice, stewards spend most of their time on the exceptions that automated matching rules cannot resolve. The steward workload scales with the volume of system-generated potential duplicates — an active MDM program with 50,000 new customer records per month may require a full-time stewardship team of three to five people.

Data policies define the rules: what fields are required for a customer record to be "complete," what match confidence threshold triggers automatic merge vs steward review, what systems are authorised to create new customer records, and what the escalation path is when two systems disagree on a customer attribute. These policies must be formally documented, approved by data owners, and enforced technically (Salesforce validation rules) and operationally (process enforcement by managers).