Data 360 Is a Reference System, Not a Database

Before I flew out I wrote that the bootcamp would be the cheap part, that the primitives are free to learn and the judgment is what costs you. I stand by it, and Draw the Boundary Before You Buy Deeper is where I said it. Then I spent the Data 360 developer bootcamp with my hands actually in the product, and one idea reorganized everything I thought I knew. Data 360 is not a database. It is a semantic layer, a reference system that sits over data you do not move.

That distinction sounds like a nuance. It is the whole thing. I came to Salesforce from the integration side, from years of MuleSoft, so my reflex when I meet any new platform is to ask where the data will live and who has to secure the second copy. Data 360 answers a different question. It does not want to be the place your data lives. It wants to be the place your data is understood.

Here is the line I wrote in my notes in capital letters and kept underlining for three days: this is a data reference system, not a data management system. Get that backwards and you will spend a fortune copying records into a tool that was built to point at them instead.

It started as a CDP

Data 360 is the product formerly known as Data Cloud, and before that it was a customer data platform in the plainest sense. Its original job was building unified customer profiles for marketers, and its two verbs were unification and segmentation. You piped in behavioral and transactional data, it resolved the duplicates into one profile, and you sliced that population into audiences. The overview still carries that DNA, and it matters, because a CDP at the core is a very different animal from a master data management system. It was never trying to be the golden source of record. It was trying to be the useful, resolved view.

What changed is the scope. The thing you build inside Data 360 now is a semantic model, a data graph, and it has grown well past customer data. It takes in unstructured data. It reaches other warehouses without copying them. The CDP grew up into a layer that describes your whole business to anything that needs to reason over it, which as of this year mostly means agents.

A reference system, not a management system

The clearest proof that Data 360 is a reference layer is where the data stays. With zero copy you point it at Snowflake or Databricks and query in place, no duplication, freshness bounded by the source. File federation extends the same idea to open table formats through Apache Iceberg, so an external lakehouse becomes queryable without an ingestion job that copies every row into Salesforce first. You are not moving the data. You are referencing it and resolving it into a shared shape.

That shape is not freeform. Data 360 ships a large catalog of predefined data model objects, and for people work the ones that carry the weight are Party, Individual, and Contact Points. The party model is the abstraction that lets a person, an organization, and the ways to reach them live as one coherent structure instead of five inconsistent tables. For regulated verticals the mappings are already drawn: the Financial Services Cloud mappings land your CRM objects onto those DMOs without you inventing the schema.

A few more things clicked into place once I held the reference-system idea in my head. A calculated insight is a view, not a materialized pile of numbers you now own and have to reconcile. The data you reach through zero copy carries a latency cost that ingestion would not, so freshness becomes a design decision instead of a default. And every transformation you run spends credits, which means the cheap-to-copy instinct I brought from integration work is exactly the instinct that runs up the bill here. Reference first. Copy only when latency or a governance boundary forces your hand.

The semantic layer grounds the agents

The reason all of this matters more than it did a year ago is that the data graph is what grounds Agentforce. An agent is only as good as its map of the business, and the semantic model is that map. When the model needs to know who a customer is, what they own, and how to reach them, it reads the resolved graph rather than guessing or querying six systems in sequence.

Two pieces made the agentic connection concrete at the bootcamp. Data 360 now exposes itself over the Model Context Protocol, with a small set of tools available today, so an agent can query the graph through the same open interface it uses for everything else. And the unstructured data support that feeds the Agentforce Data Library means the semantic layer is not limited to rows and columns. Documents get parsed and chunked and made retrievable, the same job open tools like docling do, so a policy PDF becomes part of the same grounding surface as a transaction record. The semantic layer is the model’s map, and the map now includes the prose.

Where it earns its keep, part one: segmentation and campaigns

The first place the reference layer pays off is the job it was born for. Marketing segmentation is unification and segmentation with better inputs. You resolve fragmented profiles into one person, enrich them with behavioral and unstructured signals, and build an audience from a calculated insight rather than a nightly export. The next generation of Marketing Cloud is built directly on the Data 360 data graph, so the segment you define in the semantic layer is the segment the campaign runs on, with no copy drifting out of sync in between. For a marketer this is the same promise a CDP always made. What is new is that the audience and the agent now read from the same map.

Where it earns its keep, part two: one caller, every portal

The second case is the one I care about as an architect, because it is where the reference layer solves a problem that has nothing to do with marketing.

Picture a bank the way its customers actually experience it. There is a retail banking app with one login. A wealth portal with another. A mortgage servicing site with a third. A card site with a fourth. The same human holds all four, and to the bank they look like four different people, because each portal minted its own identity and none of them agree on a key. When that person calls the contact center, the agent who picks up sees one sliver of them and has to ask the questions the other three portals could have answered.

This is exactly the problem identity resolution was built for. Data 360 collapses those fragments into one Individual with its contact points, using fuzzy matching rather than exact keys, and it scores its confidence rather than pretending the merge is certain. The engineering behind it leans on Lucene and Spark to make fuzzy matching work at population scale, with a confidence score attached to every match so you can tune how aggressive the unification is. In a regulated institution that score is not a detail. It is the difference between helpfully recognizing a customer and dangerously conflating two.

Get it right and the contact center changes shape. The agent, human or Agentforce, sees one person and one history across every portal the bank runs. The caller stops repeating themselves. And critically, the bank did not have to build a master data management program to get there. It referenced and resolved the identities that already existed in systems it already ran. That is the reference-system idea doing real work: not a new source of truth, a resolved view over the ones you have.

What I’m still weighing

The honest part. A reference system moves the hard problems, it does not delete them. Zero copy trades a storage cost for a latency cost, and for a contact center answering in real time that tradeoff is not free. Every transformation and every resolution spends credits, so the architecture has a running meter, which is the same unresolved metering problem I flagged before the conference and still have not seen anyone price cleanly. Identity resolution confidence has to be tuned and governed, because a confident wrong merge in a bank is worse than no merge at all. And a semantic layer that grounds an agent inherits every governance question the agent has, which is the whole reason the boundaries I drew before the trip still hold.

None of that changes the reframe. I walked in treating Data 360 as somewhere to put data and walked out treating it as somewhere to understand it. If you are evaluating it, resist the instinct to fill it. The certification path, Data 360 Consultant, is worth the time for exactly this reason: it trains you to model the reference layer, not to hoard records in one more place. Reference first. Copy only when you must.

---

If this resonated, read Draw the Boundary Before You Buy Deeper, the pre-conference companion on where the platform boundaries actually are, and The Data Was Always the Problem, on why the data layer decides whether any of this works.

Find me on X @orestesgarcia or LinkedIn /in/setsero.