The first time most teams encounter Salesforce Data Cloud, they reach for an analogy. “It’s a CDP.” “It’s a Salesforce-flavoured Segment.” “It’s an in-platform data lake.” Each comparison gets you a bit of the way and then leads you somewhere expensive.
Data Cloud is none of those things. It is a Salesforce-shaped data platform built around DMOs, harmonisation rules, and identity resolution, and the architectural choices that make sense when you treat it like a CDP are, almost always, the ones that make it expensive, brittle, and slow to evolve.
The CDP mental model fails on three axes
Identity. A CDP’s job is to assemble a unified profile from raw events and traits. Data Cloud’s identity-resolution engine is doing the same thing in name, but the design points are different. CDPs typically optimise for reach (match as many anonymous events to known profiles as possible). Data Cloud is sitting on top of a CRM, where profile correctness matters more than reach, and where match-rule precedence has downstream consequences across Sales, Service, and Marketing Cloud activations. Treating Data Cloud’s identity layer with CDP defaults gives you a graph that is permissive where it should be strict, and you find out three quarters in.
Modelling. A CDP encourages a flat, event-stream-first schema: traits and events, with the unified profile assembled at query time. Data Cloud rewards a structured DMO model with explicit harmonisation rules and a canonical model that other parts of the Salesforce ecosystem can rely on. Build it like a CDP and you end up with thousands of attribute fields, ambiguous derivations, and a model that no downstream consumer can plan against.
Activation. CDP activations tend to be event-driven, often into ad networks. Data Cloud activations are CRM-shaped, they update objects, drive Marketing Cloud audiences, fire flow triggers, and feed Agentforce topics. Each path has its own rhythm, ownership, and refresh cadence. Modelling all of it as “send these segments to those destinations” misses the point that the destinations have feelings, governance, and SLAs.
What to do instead
Treat Data Cloud as a production data platform that happens to live inside Salesforce.
That means: a deliberately small DMO catalogue, designed against the actual cardinality of your sources. Match rules with explicit precedence, written down. Calculated insights that are testable in isolation. Activation paths that have named owners and observable side effects. And a culture of versioning the model the way you’d version an API contract, because it is an API contract, just one that other teams in the platform consume.
The teams that get this right ship Data Cloud projects that survive their second birthday. The teams that don’t end up renegotiating consumption pricing while the model rots underneath them.
A test you can run right now
Pick the most-trafficked unified-profile attribute in your current Data Cloud implementation. Ask three questions:
- Where does this value come from? Can someone trace it back to source rules in under five minutes?
- What changes if the source disagrees? Is precedence written down, or implicit in the order rules were added?
- Who depends on it? Activations, Agentforce topics, Marketing Cloud audiences, do they all see the same answer?
If any of those are fuzzy, you have CDP modelling on a CRM platform. The remediation is real, but it’s worth doing before the consumption invoice arrives.