Data 360: principles from production
The principles Cleon applies to every Data 360 build — model first, identity as a business decision, freshness as a feature, agent-ready as a property of the model. A synthesis of official guidance, community practice, and production experience.
The principles Cleon applies when we model a Data 360 (formerly Data Cloud) org, connect a stream, write a match rule, or sign off that a segment is ready to activate. Each is anchored in implementation work, not in best-practice slides — a synthesis of Salesforce's official guidance, what the practitioner community has learned the hard way, and where Cleon's production experience departs from both.
The throughline: in Data 360 the data model is the product. Everything downstream — segments, Calculated Insights, activations, and the agents you ground on it — inherits whatever decisions you made when the model was empty and easy to change.
The principles
1. The data model is a contract — design it before the first stream connects.
A Data 360 org with thirty DMOs and no documented model is not edited, it is migrated. The model is the one decision every other surface depends on, and it is hardest to change exactly when it matters most — after data is flowing and segments are live.
Draw the model on paper before you connect the first Data Stream: the objects, their grain, their keys, their relationships. The hour you spend there is the multi-week migration you don't run later.
2. DLO is raw, DMO is meaning — don't let the lake leak into the model.
A Data Lake Object is the raw shape of whatever you ingested. A Data Model Object is what that data means in your business. The mistake is mapping a DLO to a DMO one-to-one and calling it modeling — that just relocates the source system's mess into the layer everything else reads from.
Map deliberately: rename, type, and reshape on the way from DLO to DMO so the model reads like your business, not like a database export.
3. Map to standard DMOs unless you can defend a custom one.
Salesforce ships standard DMOs — Individual, Contact Point Email, Party Identification, and the rest — and they carry semantics that downstream features and agents already understand. A custom DMO is sometimes right, but it starts with zero built-in meaning and you own every integration that touches it.
Before creating a custom DMO, answer one question: what does the standard model fail to express that this must? If you can't name it, map to standard.
4. Identity resolution is a business decision, not a checkbox.
Match and reconciliation rules decide when two records are the same person. The stakes are asymmetric and the failures are silent.
5. Data spaces are walls you build once.
A data space partitions an org's data for a real boundary — brand, region, regulatory regime. What lives in one is mostly isolated from the others, and moving data across that wall later is not a setting, it's a rebuild.
Partition for a boundary you'll still have in three years, never for short-term convenience. If two would-be spaces share an audience, they probably want to be one space.
6. Freshness is a feature.
An insight computed on last week's data is a confident wrong answer. Data 360's value is that the unified profile reflects what's true now — and that only holds if your ingestion cadence matches the decisions you make on the data.
A daily-refreshed stream feeding a real-time activation is a latency bug waiting to surprise someone. Decide the freshness each consumer needs, make ingestion meet it, and write the cadence down so the next person doesn't assume real-time where there's a 24-hour lag.
7. Calculated Insights are pre-computed truth — compute once, retrieve many.
A Calculated Insight runs the aggregation once and serves the result everywhere. The alternative — recomputing the same lifetime-value or engagement metric on the fly in every segment and every consumer — is slower, costs more, and drifts, because two consumers compute it slightly differently and now they disagree.
Define the metric once as a CI; let segments, activations, and especially agents retrieve it rather than re-derive it.
8. Activation is where the model meets the world.
Everything upstream — model, ingestion, identity, insights — is potential energy until a segment activates somewhere it does work. For Cleon that somewhere is very often Marketing Cloud: a Data 360 segment activating into an MC Journey is the bridge that connects the two platforms most clients already run.
Design the activation target as deliberately as the segment. A perfect segment activated to the wrong place is just an expensive query.
9. Consent travels with the data.
Data 360 is the layer that knows everything about a person, which makes it the right place to enforce what you're allowed to do with that knowledge — and the worst place to forget it.
10. Agent-ready is a property of the model, not a feature you bolt on.
If a human analyst can't get a coherent answer about a customer from the unified profile, neither can an agent — Agentforce or an external LLM. "Agent-ready" is not a toggle you enable at the end; it's what you already have if the model is clean, identity resolves, insights are defined, and the whole thing is documented.
The agent is just the most demanding reader your model will ever have. Build for it by building the model well.
11. Cost scales with what you process, not what you store.
Data 360 bills on the work — the rows a segment scans, the data a Calculated Insight recomputes — far more than on what sits at rest. A sloppy segment that scans the whole profile every hour is a cost decision disguised as a logic decision.
Design segments and CIs for how much they process, and revisit the expensive ones. The cheapest query is the one you didn't need to run.
12. Document the model like an API.
The next team — and the next agent — reads your model cold. Every DMO should carry a one-line statement of what it holds, what its key is, where its data comes from, and how fresh it is.
A model without that doc is a hostage situation: the knowledge lives in one person's head and the org pays rent on it forever. Cleon's Data 360 builds ship with a model doc the client team can read on a Monday morning.
Closing
These are not rules to memorize; they're the muscle you build after the same Data 360 mistakes bite at scale. They're a synthesis — Salesforce's official guidance where it's right, the community's hard-won corrections where the docs are optimistic, and Cleon's production experience where both leave gaps.
If you spot a violation of any of them in our work, write to hello@wearecleon.com — we fix it and we say so.