Data 360 architecture gotchas: the model decisions that outlast everything
The Data 360 data model looks like a setup wizard — connect a stream, map a few fields, done. The production reality is the opposite: the model is the one decision every segment, Calculated Insight, activation, and grounded agent inherits, and it's hardest to change after data is flowing. Ten model-architecture choices that bite, each with the question to answer first and the cost of getting it wrong.
Most Data 360 (formerly Data Cloud) documentation treats the data model as a wizard you run once: connect a Data Stream, accept the data lake objects it creates, map a few fields to standard objects, done. The production reality is the opposite — the model is the one decision every other surface inherits. Segments, Calculated Insights, activations, identity resolution, and any agent you ground on the profile all read whatever you decided when the model was empty and easy to change.
Ten data-model choices that bit Cleon's Data 360 builds, synthesized with Salesforce's official guidance and the corrections the practitioner community learned the hard way. Each is paired with the question to answer before the choice and the cost of getting it wrong. The framing isn't "what's the right answer" — it's "what's the question you have to be ready to defend."
The gotchas
1. DLO and DMO are not the same layer — conflating them leaks the lake into your model
A Data Lake Object (DLO) is the raw landing of an ingested stream — the source system's shape, as-is. A Data Model Object (DMO) is the harmonized, business-meaningful view that everything downstream reads from; DMOs are views over DLOs. The mistake is treating them as interchangeable: building segments or Calculated Insights directly against DLOs, or mapping a DLO to a DMO one-to-one without harmonizing anything.
The cost lands later: every downstream consumer inherits the source system's raw shape and naming, so the day a source changes a column, segments and insights silently break. Before you accept the model a Data Stream proposes, answer: for each ingested object, what is its harmonized meaning, and which DMO expresses it?
2. Mapping is where meaning gets assigned — a wrong mapping is wrong everywhere, silently
Mapping connects DLO fields to DMO attributes. It is the single most consequential step in the model, and the least visible: a field mapped to the wrong attribute, or left unmapped, throws no error. It just produces wrong or empty values in every segment, Calculated Insight, and activation that reads that attribute.
This is the failure that gets discovered weeks later, when a campaign targets the wrong people and someone traces it back to a state field mapped to country. The question to answer: who reviews every mapping against the source's actual semantics — what the field means — not just whether the column name looks right?
3. A DMO's primary key is near-permanent — choose it like you choose SubscriberKey
The primary key on a DMO determines how its records deduplicate and how other objects join to it. Once data is ingested and identity resolution has run against it, changing the key is a rebuild, not an edit — every relationship and every downstream join depends on it. Marketing Cloud veterans will recognize the shape: it's the SubscriberKey decision, one layer up.
The cost of getting it wrong is re-keying the model after it's in production. The question: what uniquely and stably identifies a row in this DMO over the record's whole lifetime — not what's convenient in the source today?
4. A custom DMO starts with zero built-in meaning — map to standard unless you can defend it
Salesforce ships standard DMOs — Individual, Contact Point Email, Party Identification, and the rest of the Customer 360 data model — and they carry semantics that identity resolution, segmentation, and Einstein already understand. A custom DMO is sometimes the right call, but it begins with no built-in meaning and you own every integration that ever touches it.
The cost is the prebuilt behavior you forfeit and the wiring you inherit. Before creating a custom DMO, answer one question: what does the standard model fail to express that this object must? If you can't name it, map to standard.
5. Data spaces are partitions you build once — partition for a boundary, not for convenience
A data space isolates an org's data for a real boundary — brand, region, regulatory regime. What lives in one space is mostly walled off from the others, and moving data across that wall later is a rebuild, not a setting.
The cost of a convenience-driven partition is a permanent wall you spend years engineering around. The question before you create a space: is this a boundary you'll still have in three years, and is its audience genuinely disjoint from every other space's? If two would-be spaces share an audience, they probably want to be one.
6. Relationships you don't model are joins you can't make downstream
DMO relationships are what let a segment or a Calculated Insight traverse from one object to another — individuals to their orders, orders to their items. A relationship you didn't model is a traversal segmentation silently cannot make: the day someone needs "individuals whose orders this quarter exceed a threshold," the filter isn't available.
The cost is discovering the gap mid-build, then changing the model with everything already depending on it. The question: what traversals will segments and insights need, and are those relationships modeled before the consumers are built?
7. Over-normalizing the model turns every segment into a multi-hop join
A model split into many tiny DMOs is clean on a whiteboard and slow in production: every useful query traverses several relationships, which costs time and consumption on each refresh. The community lesson, learned against real workloads, is to model for how the data is actually queried, not for textbook normalization.
The cost is slow segment refreshes and a consumption bill that scales with the join depth. The question: what's the common query path your segments and insights take, and does the model keep it short?
8. Ingesting PII without a consent and data-use plan bakes a compliance gap into the model
Data 360 unifies everything you know about a person, which makes it the natural enforcement point for consent and data-use purpose — and the worst place to leave them as an afterthought. Modeling consent after PII is already ingested, unified, and activating is backwards.
9. No naming convention for DLOs and DMOs is the same drift as fifty un-prefixed Data Extensions
Without a written convention, a Data 360 org accumulates dozens of objects whose purpose is a guess and whose owner is unknown — the exact drift Marketing Cloud teams know from tenants full of un-prefixed Data Extensions. It compounds because every new object makes the next one harder to name consistently.
The cost is an org that gets permanently harder to operate. The question to answer before the first object exists: what is the naming convention, and who has the authority to enforce it on every new DLO and DMO?
10. "Agent-ready" is not a default state — a fragmented or undocumented model can't ground an agent
The most modern version of this mistake: assuming that once data is in Data 360, an agent — Agentforce or an external LLM — can simply use it. But an agent reads the same model a human does. If identity doesn't resolve, relationships aren't modeled, and no object is documented, the agent inherits the same fragmented mess, and it answers confidently anyway.
The cost is an agent that's confidently wrong, which is worse than one that can't answer. The question is the honest one: can a human analyst get a coherent, complete answer about a customer from the unified profile today? If not, no agent can either.
The throughline across all ten: a clean, well-mapped, documented model is the precondition for grounding. An agent — Agentforce or an external LLM — can only retrieve what the model exposes coherently, so every gotcha above is also an agent-readiness gotcha. The work that makes a human analyst productive on the unified profile is the same work that makes it safe to point an agent at it.
Closing
These ten are the model-architecture choices Cleon has seen bite hardest in Data 360 builds. The shared theme echoes Marketing Cloud configuration: the platform makes the easy choice easy and the durable choice deliberate. Accepting the auto-generated model, skipping the mapping review, deferring consent, postponing the naming convention — none is hard in the moment, and each is a multi-week correction once data is flowing and segments are live.
The discipline that prevents most of them is the same one that prevents the MC versions: a model designed on paper and reviewed by someone who's run a Data 360 build before, with the authority to hold a go-live until the model is right.
If a data-model gotcha bit your team and isn't here, write to hello@wearecleon.com — we add it, with credit.
Reference: