Data 360 vs MDM: does the unified profile replace your golden record?

Somewhere in most Data 360 rollouts there’s a slide that retires a line item. It used to say “MDM. Evaluate,” and now it says “covered by Data 360.” The logic feels airtight: Data 360 ingests every system, resolves identities, and produces one profile per customer. That’s a golden record, isn’t it? We just bought a master data management platform without the master data management price tag.

It isn’t, and you didn’t. The gap between a Data 360 unified profile and an MDM golden record is not a matter of polish or maturity. It’s a difference in what the two things are for, and it surfaces at the worst possible time: months after go-live, when Finance and Marketing are in a room disagreeing about which customer count is correct, and nobody can point to the record that settles it. This post is about that gap. What Data 360 does to your records, what MDM does that Data 360 deliberately doesn’t, and the architecture where the two stop competing and start reinforcing each other.

Data 360 links records: it does not merge them

Start with the mechanic everyone gets wrong. When Data 360 “unifies” a customer, it does not reach into your source systems, pick a winner, and collapse three records into one. It links them. Salesforce’s own framing for this is a key ring: the unified profile is a ring, and each key on it is a source record ID pointing back to the original profile in the system it came from. The Salesforce record, the billing-system record, and the e-commerce record all stay exactly where they are, unchanged. The unified profile is a view over them, not a replacement for them.

That single design choice explains almost everything downstream. It’s why unification in Data 360 is non-destructive and reversible. Retune a match rule and the profiles regroup, because nothing was ever overwritten. It’s also why the unified profile is optimized for reading and acting, not for being the authoritative version of the truth. It was built to answer “who is this person across all our systems, right now, so I can segment, personalize, or ground an agent”, not “which value is the legally correct one.”

The unification itself runs through an identity resolution ruleset, and it has two halves worth naming precisely because teams conflate them:

Match rules decide which source profiles are the same person. Data 360 supports exact matching (literal value equality: right for email and phone), normalized matching (standardize capitalization, punctuation, and spacing before comparing), and fuzzy matching (tolerate typos and spelling variants). Four default match rules ship preconfigured; you combine and extend them with custom rules. Getting these right is its own discipline: one loose rule fuses two real people into a single profile, and we wrote the conservative-first tuning sequence precisely because that error is so easy to make and so expensive to unwind.
Reconciliation rules decide, when a unified field can only hold one value, which one shows. The documented options are Last Updated (the most recently changed value wins), Most Frequent (the value that appears most across sources wins), and Source Sequence (rank your sources most-to-least trusted and take the top one). You set these at the object level and can override them per field.

Notice what reconciliation is and isn’t. It picks a display value for the unified profile. It does not propagate that value back to your sources as the new truth, and, importantly, it doesn’t even apply to contact points: every email and phone number stays attached to the unified profile so segmentation and activation can use all of them. This is a read-side convenience, not a mastering step.

One more layer matters for this whole discussion, because identity resolution doesn’t run on raw data. Ingested data lands in Data Lake Objects, you map those into canonical Data Model Objects, and resolution runs on the mapped DMOs, the Individual DMO and its Contact Point objects, to produce the Unified Individual. If that mapping is wrong, everything above it inherits the error; it’s the step that decides everything downstream.

What an MDM golden record does that a unified profile doesn’t

Now the other construct. A golden record is not just “one profile per customer”, plenty of things produce that. A golden record is the single, governed, traceable, authoritative version of an entity, and the operative words are governed and authoritative. Three capabilities separate it from a unified profile, and none of them is cosmetic.

Attribute-level survivorship. MDM doesn’t pick a winning record; it picks a winning value for each field, under explicit rules, and treats the result as the truth. The billing address survives from the ERP because the ERP is authoritative for billing; the marketing consent flag survives from the CDP; the legal name survives from the KYC system. Survivorship is a per-attribute governance decision, not a display heuristic.

Data stewardship. When two records match at 82% confidence, somebody has to decide. MDM platforms give a human steward a console, an exception queue, and a workflow to approve, reject, or refine, and an audit trail of what they decided and why. That human-in-the-loop review is a feature, not a gap.

Writeback to systems of record. This is the one that matters most and is missed most. An MDM masters a value and then pushes it back to the operational systems, so the ERP, the billing platform, and the CRM all converge on the same governed truth. The golden record isn’t a view you read; it’s an authority that corrects its sources.

A unified profile answers “who is this, across everything, so I can act.” A golden record answers “which value is correct, provably, so I can defend it.” Personalization can run on the first. Billing, compliance, and an auditor cannot.

Add the audit trails, change history, and formal ownership that governance and regulated industries require, and you have a construct built for a different job. When Finance and a regulator need to agree on exactly one customer record and exactly one balance, “good enough to act on” is not the bar. “Provably correct, with a trail” is.

Where Data 360 stops

Salesforce is refreshingly clear about this in its own architecture guidance, even if the sales motion sometimes blurs it. Data 360 is not a system of record. It never generates the first version of a record; it needs a source system to do that. It does not master attributes into an authoritative truth, and it does not, by default, sync a governed value back across all your source systems.

That last point deserves a careful caveat, because there’s a real feature next to it that’s easy to over-read. Data 360 can write things back, through Data Actions, activation, and Calculated Insights, it can push scores, segment membership, event summaries, and computed metrics into Salesforce CRM and downstream systems. That’s useful, and it’s covered in the ways data leaves Data 360. But it is enrichment and activation, not mastering. Writing a churn score or a segment flag onto a Contact is not the same as reconciling the customer’s legal address across six systems and making everyone agree. Conflating the two is exactly how a team convinces itself it has MDM when it has a very good activation layer.

There’s also Data 360 Governance. Policy-based classification and tagging of your unified data and metadata, authored declaratively across ingested and zero-copy sources. It’s real and worth using. It is also governance of data access and classification, not the survivorship-and-stewardship engine of an MDM. Don’t let the word “governance” collapse the distinction.

The honest one-liner: Data 360 makes your data usable and unified for action. MDM makes a subset of it authoritative and defensible. Those are different verbs.

The coexistence pattern that works

Here’s the part the “vs” framing hides: for most enterprises the answer isn’t one or the other, it’s a layered architecture where each does the job it’s built for.

The pattern practitioners keep landing on is MDM masters, Data 360 activates:

MDM governs the core. For the handful of entities and attributes that must be authoritative (the customer’s legal identity, the account hierarchy, regulated attributes) MDM does the matching, survivorship, stewardship, and writeback. It’s the system of truth.
The golden record feeds Data 360 as a source. Those clean, governed records become one of Data 360’s ingested sources, usually a high-priority one in your Source Sequence reconciliation, so the mastered value wins on the unified profile.
Data 360 does what MDM can’t. It stitches in the high-volume behavioral and engagement data MDM was never meant to hold (web events, product usage, service interactions) resolves identity across all of it, and activates: segmentation, personalization, and grounding for Agentforce agents.

Governed truth flows up into the activation layer; behavior and engagement flow around it; the agent and the campaign read a profile that is both governed where it needs to be and rich everywhere else. Neither layer is pretending to be the other.

If your governance need lives inside Salesforce rather than in a separate enterprise MDM, there are Salesforce-native operational MDM options on the AppExchange, clearMDM being the most established, that do cleanse/match/merge/survivorship/stewardship on CRM records directly, and they position themselves as complementary to Data 360 rather than competitive with it. That’s the tell: even the MDM vendors building on the platform don’t claim Data 360 replaces them.

And it’s worth watching the platform itself here. Salesforce closed its acquisition of Informatica in November 2025 and has begun folding Informatica’s MDM, data quality, catalog, and governance capabilities into the platform under the “Informatica from Salesforce” banner. Read that as the strongest possible signal about the question this post is asking: if the unified profile already were a golden record, Salesforce would not be buying an MDM company to sit next to Data 360. Treat the specifics as a moving target, check current availability and packaging before you architect around it, but treat the direction as settled.

A short decision framework

You can usually place a project in one of three buckets in an afternoon.

Data 360 alone is enough when the goal is unification for action (segmentation, personalization, real-time engagement, and grounding AI) and no downstream process demands a single legally or financially defensible record. Most marketing and service use cases live here. If “good enough to act on” is good enough, you don’t need to buy governance you won’t use.

You need MDM when a business process depends on one authoritative value that has to be correct, traceable, and consistent across systems: billing, regulatory reporting, KYC, entity hierarchies in financial services, clinical or safety data. The tells are the words audit, survivorship, stewardship, and writeback. If any of them are hard requirements, a unified profile will not satisfy them and no amount of match-rule tuning will change that.

You need both when you have both shapes of problem, which, at enterprise scale, is the common case. Master the governed core in MDM, feed it into Data 360, and let Data 360 activate on top. That’s not indecision; it’s the correct architecture.

The mistake to avoid is the one we opened with: deleting the MDM line because the unified profile looks like a golden record in a demo. It links where MDM masters, it displays where MDM governs, and it reads where MDM writes back. Know which verb your business needs before you decide the other tool is redundant, because the day Finance and Marketing disagree about the customer count is a bad day to discover the difference. If your unified profile is drifting from a truth nobody owns, that’s usually a data-quality and governance problem wearing a unification costume, and it’s worth naming correctly before you scale an agent on top of it.

Understanding the basics

Is Salesforce Data 360 an MDM?

No. Data 360 (formerly Data Cloud) is a customer data platform: it links records across systems into a unified profile optimized for segmentation, activation, and grounding AI. An MDM produces a governed, authoritative golden record with attribute-level survivorship, data stewardship, audit trails, and writeback to source systems. Data 360 links and displays; MDM masters and governs. Data 360 can complement an MDM, but it does not replace one for system-of-record or compliance use cases.

What is the difference between a unified profile and a golden record?

A unified profile is a linked view. Salesforce calls the model a “key ring,” where each source record ID stays intact and the profile points to all of them. It’s read-optimized and reversible. A golden record is the single authoritative version of an entity, built with governed survivorship rules and stewardship, and pushed back to operational systems as the truth. The unified profile answers “who is this across everything”; the golden record answers “which value is provably correct.”

Does Data 360 write data back to my source systems?

Not as a mastering step. Data 360 can write enrichment (scores, segment membership, calculated metrics, event summaries) back to Salesforce CRM and downstream systems via Data Actions, activation, and Calculated Insights. That is activation, not mastering. It does not reconcile an authoritative attribute value and sync it across all your systems of record the way an MDM does. Don’t mistake enrichment writeback for golden-record writeback.

When do I need MDM if I already have Data 360?

When a business process requires a single authoritative record that must be correct, traceable, and consistent across systems: billing, regulatory reporting, KYC, entity hierarchies. The signals are hard requirements for survivorship, stewardship, audit trails, or writeback. In those cases the common enterprise pattern is to master the governed core in MDM, feed it into Data 360 as a high-priority source, and let Data 360 handle behavioral data, identity resolution across everything, and activation on top.

Trying to work out whether a unified profile is enough or you need governed master data underneath it, and how to layer the two without paying twice? Talk to us. Getting the data foundation right is the difference between an agent that helps and one that confidently reports the wrong customer count.