Your identity graph is the single most consequential object in your customer data platform, and most people who run Salesforce Data 360 believe they can’t see it. They picture a sealed engine that swallows records, does something proprietary, and emits a “unified profile” — a black box you configure but never inspect.

That belief is wrong, and it’s worth correcting, because it drives teams to either distrust their own data or rip out a platform that’s more open than they think. Data 360 exposes your identity graph as queryable data — the link tables, a REST lookup, and zero-copy access from your warehouse are all documented in Salesforce’s own identity-resolution reference. The graph was never hidden.

The real problem is narrower, and more interesting. Data 360 tells you which records were merged into a profile, but not why they were merged, and it gives you no way to test a match-rule change before it ships. Those two gaps are where identity work actually goes wrong — and, as it turns out, they’re the two things you can close yourself without leaving the platform.

An identity graph is nodes and edges, not a vendor feature

Strip away the branding and an identity graph is a plain data structure: nodes and edges. The nodes are every identifier you hold for a person — a browser cookie, a device ID, a hashed email, a phone number, a CRM contact ID, a loyalty number, an authenticated login. The edges are assertions that two of those identifiers belong to the same human being.

Those edges get created two ways. Deterministically, by matching on a shared strong key — the same verified email appears in your web analytics and your order system, so the two records are the same person. Or probabilistically, by inferring a match from weaker signals that individually prove nothing but together clear a confidence threshold — same device, same surname, same postal area, resolving three fragments of “Jane” into one profile instead of leaving her as three strangers.

This structure is quietly the foundation of everything the platform does downstream. Without it, Jane-the-web-visitor, Jane-the-email-subscriber, and Jane-the-purchaser are three unrelated rows; with it, they collapse into one profile carrying one stable ID. That unified ID is what you segment on, personalise against, suppress by, and measure with. Get the edges too loose and you fuse two different people into one profile — activating on, and reporting against, a customer who doesn’t exist. Get them too tight and you silently drop real customers who should have matched. Every identity decision that matters is a decision about an edge.

Data 360 already hands you the graph as queryable data

Here’s the part the black-box story gets wrong. When Data 360 runs identity resolution, it doesn’t just emit profiles — it writes the graph to tables you can read.

Those tables are the Unified Link Objects. Identity resolution creates them as a bridge between your source records and the unified profiles, and each row records the mapping: a Source Record ID, the Unified Individual ID it resolved into, the data source, and the data source object. That is the edge list. Query the link object for a given Unified Individual ID and you get, in plain rows, every source record that was stitched into that profile and where each one came from. Salesforce also ships a REST endpoint, universalIdLookup, whose entire job is to “retrieve all individual records associated with a unified record across different data sources” — the same composition, on demand, per profile.

And you don’t have to work inside the platform to use any of it. Through Zero Copy, Data 360’s unified and link objects are readable directly from Snowflake and BigQuery without copying the data out — you query the graph from your own warehouse, alongside everything else you have. (This is also why the “the graph is trapped in Salesforce” objection doesn’t hold: the mapping isn’t locked in, it’s shareable.)

So the honest concession the warehouse-native crowd usually skips: on visibility, Data 360 is genuinely good. You can see the graph, per profile, as data, from your warehouse. If all you needed was to know which records make up a customer, you already have it, and building a parallel graph would be reinventing a wheel Salesforce already gave you.

The edge tells you that records merged — not why

The link object records that three records resolved into one profile. What it does not record is which match rule fired, on which fields, at what confidence. There is no “matched by the household-address rule at 0.82” column on the edge. The mapping is there; the reasoning is not.

Walk through what that costs with a concrete case. A support agent flags that Jane Doe and her adult daughter Jenny — same surname, same address — have collapsed into one Unified Individual. You query the link object and confirm the merge immediately: three source records, web plus loyalty plus point-of-sale, all under one ID. Good — you can see it. But your ruleset has five match rules. Was it the address rule? The fuzzy-name rule? The phone rule that caught a shared landline? The edge doesn’t say, so you can’t tell which rule to touch.

This is where the gap stops being academic. The merged profile now activates and reports as one customer assembled from two real people. Jenny is being marketed to on Jane’s purchase history — and because consent merged along with everything else, on an opt-in that was never hers. That is a live privacy exposure: you’re profiling and messaging a person on someone else’s legal basis, and every segment, suppression check, and revenue report that touches this profile is now quietly wrong. You can see the error perfectly. You just can’t attribute it, so you can’t fix it surgically.

You can’t test a rule change before it ships

With no way to know which rule caused the merge, your only move is to tighten a rule you suspect and re-run resolution — blind. Data 360 gives you no preview of who else that change would affect before you commit it.

That’s the second gap, and it’s the more dangerous one. Suppose you tighten the rule that fuses records on shared address. It un-merges Jane and Jenny, which is what you wanted. It also splits 4,000 other customers who were correctly matched on address plus corroborating signals — households where the address rule was doing legitimate work. You find out only after the fact, because nothing showed you the blast radius in advance.

Now those 4,000 people fragment back into duplicate profiles, and the damage propagates: suppression breaks, so you email customers who explicitly opted out; frequency caps break, so you over-contact; your customer count inflates; and your attribution double-counts revenue across the split fragments. You fixed one visible error and introduced thousands of invisible ones.

That is the real dilemma Data 360 forces, and it’s worth stating plainly because it’s the reason the two gaps matter at all: faced with a mis-merge you can see but can’t attribute, you must choose between leaving a known consent error in place, or shipping a blind correction that silently damages profiles you had no way to see coming. Neither option is one a careful data team should have to accept.

Close both gaps in your warehouse — without leaving Data 360

Here’s the resolution, and it follows directly from the first half of this post. Because the link objects are already readable in your warehouse through Zero Copy, you don’t need to replace Data 360’s resolution engine — you need to build a thin layer on top of the graph it already shares.

Rebuild the graph as models in your warehouse — SQL or dbt over the link objects and your source tables — and do the two things Data 360 doesn’t. First, stamp each edge with its provenance: as you reconstruct the matches, attach the rule and the matched fields to every link, so that when Jane and Jenny merge, one query tells you it was the address rule, not a guess across five candidates. Second, snapshot and diff: keep versioned copies of the graph, and before you promote a rule change, compute the graph with the change and diff it against the current one. The 4,000 splits show up as a diff you read on Monday, not an incident you discover on Wednesday.

Be clear about what this is and isn’t. It is not a rip-and-replace, and it is not an argument that Data 360’s matching is bad — its deterministic and AI-based matching are fine, and for plenty of teams the platform as-is is entirely sufficient. If you activate solely through Data 360, don’t need identity shared across other tools, and your matching rarely mis-merges, you may never need this layer at all. It earns its keep specifically when you operate identity at a scale where the why of a match and the safety of a change have real consequences — regulated consent, high-value merges, fraud-adjacent linking. For those teams, the layer is additive: Data 360 keeps resolving, and your warehouse gives you the audit trail and the test harness the platform leaves out.

Conclusion

The identity graph was never the black box the warehouse-native pitch makes it out to be. Data 360 hands you the edges as data — link objects, a lookup API, and zero-copy into your warehouse — and any story that starts with “you can’t see your graph” is arguing against a problem Salesforce already solved. Believe that story and you’ll either distrust data you can actually inspect, or tear out a platform for a gap it doesn’t have.

The gaps that are real are narrower and sharper: the graph records which records merged but not why, and it offers no way to test a match-rule change before it ships. Those two — attribution and change-safety — are where identity work quietly breaks, and they’re precisely the two you can close on top of what the platform already exposes.

The Monday-morning move is a five-minute diagnostic, not a project. Pull one profile you suspect is over-merged, query its link object for the source records underneath it, and try to explain — from the data alone — which rule fused them. If you can, your graph is in good shape. If you can’t, you’ve just found the exact gap this post is about, and you now know where to build.

Where to go next

If you want the foundation under all of this, start with our identity resolution pillar — it lays out how matching, rulesets, and unified profiles fit together before you decide what to build on top. It’s the right next read if you’re weighing whether an audit-and-simulation layer is worth it for your team, or whether Data 360’s defaults already cover you.

Frequently Asked Questions

What’s the difference between an identity graph and identity resolution?

The identity graph is the structure — the nodes (identifiers) and edges (same-person links) that map which records belong to whom. Identity resolution is the process that builds and maintains it: the match rules and reconciliation logic that decide when two records become one. Put simply, resolution is the verb and the graph is the noun it produces.

Is Data 360 the same thing as Salesforce Data Cloud?

Yes. Data 360 is the current name for the product Salesforce previously called Data Cloud; it was renamed in 2025 under the Agentforce 360 platform. The identity-resolution mechanics — strong-key matching, native AI-based matching, rulesets, and the link objects — did not change with the rename.

Can you export the identity graph or unified profiles out of Data 360?

You don’t have to export it in the old copy-it-out sense. Through Zero Copy, the unified profiles and the Unified Link Objects are queryable directly from Snowflake and BigQuery, so you can read the graph from your warehouse without duplicating the data. The Unified Individual IDs are Salesforce-generated, so leaving the platform still means rebuilding the resolution logic — but the data itself is accessible, not locked in.

Does Data 360 use deterministic or probabilistic matching?

Both. Deterministic matching links records on shared strong keys like a verified email or phone number, and is the default most teams run. Data 360 also offers native, AI-based matching that returns a confidence score rather than a blunt yes/no, which recovers customers that exact-key matching alone would miss. The two are configured together in a ruleset.

What is a “customer identity graph” built from first-party data, versus a third-party identity graph?

A first-party identity graph — the kind Data 360 builds — resolves identities using data you collected and own, and it’s the graph that governs your own personalisation, suppression, and measurement. A third-party identity graph (the LiveRamp-style variety) links identifiers across the wider ad ecosystem for reach and targeting, using data you don’t control. They solve different problems; this post is entirely about the first-party graph inside your CDP.

Do you still need a warehouse-native identity graph if you already run Data 360?

Not always. If you activate solely through Data 360, don’t need a shared identity spine across other tools, and rarely mis-merge, the platform’s own graph is enough. A warehouse-native layer earns its place when you need to audit why a specific match happened, or test a rule change before it ships — needs that show up at regulated, high-value, or fraud-adjacent scale, and that Data 360 doesn’t cover on its own.