Master Data Management (MDM)
A customer exists in two Salesforce orgs and an ERP. Each system has a different name, address, and identifier for the customer. Before synchronizing those records, the architect must decide whether they represent the same entity, which system can change each attribute, and how conflicts are resolved.
Master Data Management defines the ownership, identity, quality rules, and lifecycle of shared business entities such as customers, products, suppliers, and locations. In this article, MDM means Master Data Management; Mobile Device Management is a separate topic.
For a CTA solution, make five decisions explicit: what is mastered, who owns it, how records are matched, which values survive, and how approved changes reach consumers. The worked example below is an illustrative architecture, not a prescribed Salesforce implementation.
Decide whether you need MDM
| Requirement | Starting point | Remaining architectural decision |
|---|---|---|
| Prevent duplicate Accounts inside one Salesforce org | Matching and duplicate management | Match criteria, exceptions, and merge permissions |
| Connect customer profiles across channels while preserving source records | Data Cloud / Data 360 identity resolution | Matching, reconciliation, permitted uses, and downstream actions |
| Govern customer identities and attributes across independently operated systems | An MDM capability with business stewardship | Attribute ownership, lifecycle, distribution, and conflict handling |
| Copy approved changes between systems | Integration services or middleware | The ownership and quality rules the integration must enforce |
These capabilities can work together. Identity resolution creates linked, unified profiles; it does not by itself establish an operational process for correcting every source record. Local duplicate prevention also does not establish enterprise ownership. Salesforce describes these distinctions in Compare Customer Profile Unification Approaches.
An external MDM platform is a design choice. For a narrow domain with one authoritative application, a documented ownership model and reliable integration may be sufficient. Justify a dedicated hub through the number of competing sources, matching complexity, stewardship workload, and business need for governed distribution.
Choose an implementation style
| Style | Where changes originate | Hub responsibility | Main trade-off |
|---|---|---|---|
| Registry | Existing source systems | Match identities and maintain links between source records | Limited disruption, but source quality and availability still matter |
| Consolidation | Existing source systems | Assemble a persisted golden record for shared reference and analytics | A trusted central view does not automatically correct operational sources |
| Coexistence | Sources and hub, under defined ownership rules | Reconcile records and distribute approved values | Supports existing workflows but requires conflict and synchronization controls |
| Centralized / transaction | A centrally governed authoring process | Maintain authoritative master data and publish it to consumers | Strong control, with greater workflow change and dependency on the hub |
This terminology follows Stibo Systems' overview of the four implementation styles. A landscape can use different styles for different domains; choose explicitly for the customer, product, or supplier problem in the scenario.
Define ownership at attribute level
“Salesforce owns the customer” leaves too much unspecified. Separate the system authorized to maintain an attribute from the business owner accountable for its meaning and quality.
Consider this example policy for two regional Salesforce orgs, two regional ERPs, and a customer MDM hub:
| Attribute | Authorized source | Behavior in Salesforce | Conflict policy |
|---|---|---|---|
| Enterprise customer ID | MDM hub | Protected after assignment | Route conflicting identity links to a steward |
| Legal name and tax identifier | ERP responsible for that legal entity | Display approved values; submit correction requests | The responsible ERP wins after validation |
| Billing address | Responsible ERP | Read-only operational copy for sales users | An approved address change replaces the previous value |
| Sales relationship owner | Relevant Salesforce org | Editable by authorized sales operations users | Preserve regional ownership; do not collapse it into one global owner |
| Verified contact phone | Authorized customer-service process | Editable through that process | Prefer a verified value; recency breaks ties only within equally trusted sources |
Document what constitutes a customer: legal entity, branch, household, or person. Parent and subsidiary companies may be related without being duplicates. A hierarchy should preserve those relationships separately from identity matching.
Build the golden record deliberately
A golden record is the governed representation selected from available source values. Survivorship determines which value is retained for each attribute after records have been identified as belonging to the same entity.
In the example, the ERP supplies Northstar Manufacturing Ltd and a verified billing address. Salesforce supplies Northstar Mfg and a newly verified service phone. The proposed golden record retains the ERP legal name and billing address, plus the verified service phone. It also retains the source, verification status, and decision history for each selected value.
Use this processing sequence:
- Normalize: standardize phone formats, country codes, whitespace, and address components while retaining original source values.
- Match: use trusted identifiers within their scope, such as country plus a validated registration identifier. Treat fuzzy names and addresses as supporting evidence.
- Review ambiguity: separate automatic linking, steward review, and no-match outcomes. Calibrate thresholds against representative labeled data and the cost of false matches.
- Select attributes: apply approved source priority, validation status, and permitted recency rules. Define whether a blank means unknown or an intentional deletion.
- Publish: distribute an approved version and retain the evidence needed to explain or reverse the identity decision.
Do not invent a universal “95% match” rule for the board. Explain how the business will validate thresholds. A false merge could expose one customer's cases to another; a missed match could produce duplicate service histories. Those consequences warrant different controls.
Map identifiers across systems
Keep a cross-reference keyed by source system + source record ID:
| Source system | Source record ID | Enterprise customer ID |
|---|---|---|
| Salesforce Europe | Account-EU-42 | CUST-008731 |
| Salesforce North America | Account-NA-91 | CUST-008731 |
| ERP Europe | Debtor-51020 | CUST-008731 |
These are illustrative identifiers. The mapping belongs in the governed identity service or hub and must support retired IDs, merges, and corrected links.
If each Salesforce org permits one Account per enterprise customer, configure an appropriate Enterprise_Customer_ID__c field as External ID and Unique. Salesforce's External ID upsert resource can then locate a record for creation or update. External ID matching can return multiple matches when uniqueness is not enforced.
If the org deliberately maintains several Accounts for one customer, for example by business relationship, use a separate unique integration key for each local Account and retain the enterprise ID as a shared reference. Decide that cardinality before choosing the upsert key.
Worked CTA scenario: coexistence across regional systems
Assumptions: both sales teams must continue working in their regional orgs; the ERPs remain authoritative for billing attributes; approved customer changes should reach relevant consumers within five minutes; the business permits the hub to hold the specified customer attributes. Five minutes is an example requirement, not a platform guarantee.
Choose coexistence because approved changes must return to operational systems while existing applications retain their authoring responsibilities. A registry would link identities but would not deliver the required corrections. Centralized authoring would require a larger change to sales and ERP workflows.
The integration flow has distinct responsibilities:
Regional Salesforce orgs ---- authorized customer changes ----+
|
Regional ERPs -------------- billing and legal changes -------+
v
Durable integration layer
|
v
MDM hub + steward review
|
approved customer version
v
Durable integration layer
|
relevant Salesforce orgs and ERPs
This is a logical flow; arrows do not imply one Salesforce API or a distributed transaction.
Use Change Data Capture for supported Salesforce record changes when change notifications fit the requirement. Use a deliberately designed Platform Event contract when the business needs an explicit action such as CustomerCorrectionRequested. Select inbound APIs and batching around volume and latency. Salesforce's Integration Patterns provides the request/reply, asynchronous, batch, and remote call-in patterns underlying these choices.
In this design, a newly created Account remains Pending mastering until identity resolution finishes. Service work may continue, but order activation requires an ERP customer identifier and approved billing data. If the business instead requires verified identity before Account creation, synchronous validation is an alternative with an explicit availability dependency and timeout behavior.
Make synchronization recoverable
The proposed integration contract carries the enterprise ID, originating system, source key, correlation ID, and approved master version. Apply these controls:
| Failure | Proposed handling |
|---|---|
| A delivery is retried | Use a durable processing ledger and idempotent writes; avoid repeating business side effects |
| An older master version arrives after a newer one | Compare the per-customer version and reject stale updates |
| An approved write generates another outbound change | Apply attribute ownership, origin tracking, and change comparison so an echo is not treated as a fresh proposal |
| A source sends an invalid value | Quarantine the proposal, keep the last approved value, and assign an actionable exception |
| A consumer is unavailable | Queue approved changes durably, retry with backoff, and alert on age and backlog |
| Delivery history is incomplete | Reconcile source and target keys, versions, and values; repair from an authoritative snapshot or delta |
An upsert helps identify the target record, but it does not make every trigger, notification, or downstream action idempotent. Test repeated delivery end to end.
Salesforce retains platform events and CDC events for 72 hours. Replay IDs identify stream positions and must not be treated as permanent business identifiers. For this architecture, persist work durably and provide reconciliation beyond event replay; the event bus is not the sole recovery store. See Event Message Durability.
Plan stewardship and rollout
Assign a business data owner to approve definitions and survivorship policies. Give data stewards queues for ambiguous matches, conflicting identifiers, and correction requests. Assign integration operations responsibility for failed delivery and reconciliation. Monitor match errors, unresolved exceptions, propagation latency, and stale consumers separately.
For the example rollout:
- Profile a regional sample and agree on entity definitions, mappings, and attribute ownership.
- Establish a baseline extraction and change-capture handoff so updates made during migration are retained.
- Resolve identities and populate the cross-reference before loading dependent records. Reuse the data migration planning material, with explicit controls for this implementation.
- Run matching in observation mode and have stewards assess proposed links before enabling automatic decisions.
- Enable approved distribution for one region, verify reconciliation, and expand after agreed acceptance criteria are met.
- Exercise duplicate delivery, a prolonged outage, a false match, and rollback. Define which writes pause and how queued changes resume.
Linking records must not broaden users' access. Apply the target org's sharing and field access rules to replicated data, and agree which attributes may cross regional boundaries. Maintain a process for correcting mistaken links and propagating authorized deletion or restriction requests to affected consumers without reintroducing retired data.
Defend the decision at the Review Board
Be ready to answer:
- Why does this scenario need governed mastering rather than local duplicate prevention?
- Who can change each shared attribute, and how is that enforced for users and integrations?
- Why is coexistence appropriate, and what operational complexity does it introduce?
- What can a user do while the hub is unavailable or identity resolution is pending?
- How will you detect stale consumers and recover after the replay window?
- How will you correct a false match and preserve access boundaries?
An example justification is: “I propose customer MDM in coexistence mode because both regional ERPs and Salesforce orgs retain operational responsibilities. The responsible ERP owns billing attributes, Salesforce owns regional sales relationships, and the hub governs identity and approved shared values. Durable delivery, version checks, stewardship, and reconciliation support the required consistency. The trade-off is additional operational complexity and eventual consistency between systems.”