Data 360 Data Architecture: Style Guide | Cleon

This is the page where Cleon stops describing what the Data 360 (formerly Data Cloud) model is and starts saying what we do with it. Salesforce defines what's possible. The reference pages in this subcategory document each surface — DLOs, DMOs, data spaces, relationships and keys. The gotchas document the choices that compound. This Style Guide is the discipline that keeps a Data 360 model trustworthy a year after the build — and, because the model is what an agent reads, the discipline that makes it safe to ground Agentforce or an external LLM on it.

Use it as a checklist before any model change ships: a new DMO, a new mapping, a new data space, a relationship, a key. The rules are short on purpose — when a rule needs an explanation, the explanation is in the page it links to.

Naming

DLOs and DMOs follow a written convention, decided before the first object exists

A naming convention for objects and attributes, written down and enforced in review, before the first DLO lands. Drift on naming is the same compounding debt as fifty un-prefixed Data Extensions in Marketing Cloud. (See gotchas — gotcha 9.)

Custom DMOs are named for meaning, not for source

A custom DMO name reflects what it means in the business (LoyaltyAccount), not the system it came from (SAP_ZTABLE_07). The name is the documentation the next modeler reads first.

Data spaces are named for the boundary they enforce

Per data spaces. The name encodes the boundary — brand, region, regulatory regime — so the partition's reason is visible without asking.

Modeling discipline

Design the model on paper before the first stream connects

Per gotchas — gotcha 1. Objects, grain, keys, relationships, drawn before ingestion. The model is the decision every other surface inherits.

Keep the DLO raw and the DMO meaningful

Per gotchas — gotcha 2, and mapping. Harmonize on the way from DLO to DMO; never map one-to-one and call it modeling.

Map to a standard DMO unless you can name what's missing

Per DMOs and gotchas — gotcha 4. Standard objects carry semantics that identity resolution, segmentation, and agents already understand. Custom is ownership you take on deliberately.

Choose a stable primary key, at creation

Per relationships & keys and gotchas — gotcha 3. What uniquely and stably identifies a row over its lifetime — the SubscriberKey discipline, one layer up.

Model the relationships consumers will need, before the consumers

Per relationships & keys and gotchas — gotcha 6. An unmodeled relationship is a traversal segmentation silently can't make.

Partition data spaces for a real boundary, not for convenience

Per data spaces and gotchas — gotcha 5. A data space is a wall you build once. Default to one space.

Documentation discipline

Document the model like an API

Per gotchas — gotcha 12. Every DMO carries a one-line statement: what it holds, its key, its source, its freshness. A model without that doc is a hostage situation.

Model consent and data-use purpose alongside the data

Per gotchas — gotcha 8. Data 360 is the enforcement point. A segment must not be able to activate a person into a channel they opted out of.

Write the freshness of every stream down

A consumer needs to know whether a field is real-time or a day stale. The cadence lives in the model doc, not in someone's memory.

Patterns to prefer

Standard DMO over custom, every time you can name the standard object that fits.
One data space until a boundary genuinely demands a second.
Calculated Insights for shared metrics — compute once, retrieve many (especially for agents).
Normalize at the mapping layer, so every downstream consumer reads the same clean value.
A model review by someone who's run a Data 360 build before, with authority to hold a go-live.

Patterns to refuse

Business logic against DLOs. Build on DMOs. (Per DLOs.)
A custom DMO you can't justify against the standard model.
A data space created for organizational convenience.
A mapping shipped without a field-by-field review against the source's real meaning.
PII ingested before consent is modeled.
"We'll document it later." Day-one documentation costs hours; six-month documentation costs days.

The agent-readiness check

Data 360's modern job is to be the data an agent — Agentforce or an external LLM — can ground on. "Agent-ready" is not a feature you enable; it's the state you're already in if the model is built well. Before pointing any agent at the unified profile, confirm:

[ ] A human analyst can get a coherent, complete answer about a customer from the unified profile.
[ ] Identity resolution unifies the right records — no two customers merged, no one customer split.
[ ] The relationships an agent's questions imply are modeled (person to orders to items).
[ ] Shared metrics exist as Calculated Insights the agent retrieves, not values it recomputes.
[ ] Every DMO is documented — meaning, key, source, freshness.
[ ] Consent and data-use purpose are enforced in the model, so an agent can't act past them.

If any box is unchecked, the model isn't agent-ready — and an agent grounded on it will be confidently wrong. The work above is the same work that makes a human analyst productive; the agent is just the most demanding reader.

The discipline check before any model change ships

[ ] The change is documented — meaning, key, source, freshness, rationale, owner.
[ ] Naming follows the convention for the object type.
[ ] New DMO: mapped to standard, or a named justification for custom.
[ ] New or changed key: stable over the record's lifetime; set at creation, not retrofitted.
[ ] New relationship: cardinality matches reality and is documented.
[ ] New data space: the boundary is real and the audience is disjoint.
[ ] Mapping reviewed field-by-field against the source's real meaning.
[ ] Consent and data-use modeled for any new PII.
[ ] The agent-readiness check above still passes after the change.

When all of them fire, the model change is ready to ship.

Data 360 principles from production — the meta-rules above these specifics
Data 360 architecture gotchas — the choices this Style Guide is designed to prevent compounding
Data Lake Objects (DLOs) — the raw landing layer
Data Model Objects (DMOs) — the harmonized layer
Mapping DLOs to DMOs — how meaning gets assigned
Data spaces — the boundary the model lives within
Relationships & keys — how objects connect and dedupe
Debugging mapping failures — when a value lands wrong or blank

If you spot a rule missing — or one of these rules being violated in our public work — write to hello@wearecleon.com. We add it, or we fix it and we say so.