Data 360 Doesn't Build a Golden Record. So What?

Put a group of people in a room to design identity resolution, and someone will ask which email is the real one. It’s a fair question. Most of us learned customer data from master data management, where the goal is one golden record: one name, one address, one email, and everything else thrown away.

Salesforce Data 360 (formerly Data Cloud) doesn’t work that way.

The concept in one sentence

Identity resolution links a person’s records into one unified profile, but it never merges them, overwrites them, or deletes them; every source record and every email address is still there afterward.

I’ve written about how that works: think of a keychain, not a melted-down super-key. This post is about the part that usually gets skipped. So what?

So what?

“Which email?” isn’t answered by identity resolution at all. Reconciliation rules decide what the unified profile displays, like which spelling of a name wins. They don’t touch contact points. Every email stays attached, and the choice happens later, at activation, every time you send. Source priority picks one per channel, then engagement score, then the lowest ID.

Take Robert Chen, the fictional customer in my activation tool. His marketing email goes to an address he rarely opens, while the address he reads every day sits right there on his profile. Nothing broke. The activation was set to prefer Marketing Cloud’s primary email, and that’s the one Marketing Cloud had. You can watch it happen here, and change the setting that caused it.

It’s reversible. A golden record is hard to take back. Merge two customers who shouldn’t have been merged, and the values you overwrote are gone from the master record; unwinding it is a cleanup project. In Data 360, a bad match is just a link. Tighten the rule, run it again, and the profiles come apart with their data intact. That makes it cheap to experiment, which is exactly what you should be doing before go-live. The identity resolution simulator exists for that.

Your source systems stay the system of record. Data 360 sits beside your CRM, not on top of it. It doesn’t dedupe your Contacts or pick a winner and write it back. If the business wants one clean record in CRM, that’s a separate project with its own decisions, and it’s worth saying so out loud before someone assumes the unified profile already did it.

Two versions of the truth are sometimes both true. A billing address and a shipping address. A personal email and a work email. A golden record forces a choice that the business never actually needed to make. Linking lets each channel use the value that fits it.

What goes wrong when teams miss this

It shows up in three places.

The first is the design session that stalls. People spend an hour debating which email is correct for every customer, a decision identity resolution will never make, when they should be talking about match rules and how wrong a merge is allowed to be.

The second is reporting. Someone builds a report against the source records, expecting one row per person, and gets three. Or they query the unified profile and are surprised to find every email still there.

The third is the one that costs real money: the send. The segment count looks right, the activation looks smaller than expected, and the emails that do go out land at the wrong address. Every one of those traces back to contact point settings, not identity resolution, but that’s the last place anyone looks when they believe identity resolution picked a winner.

None of these are bugs. They’re a mental model borrowed from a different kind of system.

The question to ask your team

Before anyone writes a match rule, ask this:

“When two systems disagree, who needs one answer, and who needs to keep all of them?”

Marketing usually needs one address per send, chosen fresh each time. Service usually needs to see every address the customer has ever given you. Finance needs the billing address and nothing else. Data 360 can serve all three, but only if you stop expecting identity resolution to be the one that decides.

If you’re earlier than that, start with what to settle before configuring a single rule, and see data harmonization for the step that decides which contact points exist to link in the first place.