Data Lake Objects vs Data Model Objects in Data 360: the mapping step that decides everything downstream

You connect a source to Data 360, create a data stream, and it works — the records land, you can query them, the row counts look right. So you build a segment on top of them, and it’s empty. Or you run identity resolution and nothing unifies. Or you point an agent at the data and it can’t find anything. Every time, the same missing step is the cause: the data arrived, but it was never mapped. It’s sitting in a Data Lake Object, and almost everything you want to do in Data 360 reads from a Data Model Object instead.

This is the concept that trips up nearly everyone learning the platform, and it’s not a beginner’s confusion you outgrow — getting the Data Lake Object to Data Model Object relationship wrong is behind a large share of the “why is my segment empty” and “why won’t this unify” tickets in mature orgs too. The two object types look similar in the UI, they hold overlapping data, and the difference between them is conceptual rather than visual. But that difference is the whole architecture: one is storage, the other is meaning, and the mapping between them is where you tell Data 360 what your data actually is.

Here’s what each object is, why the platform splits them, and the mapping decisions that determine whether the layers above — unification, segmentation, insights, and agent grounding — work at all.

Two objects, two jobs

Strip the vocabulary and the split is simple:

A Data Lake Object (DLO) is where ingested data lands, in the shape the source gave it. Create a data stream — a CSV upload, the Salesforce CRM connector, an Amazon S3 ingestion, a Marketing Cloud feed, a Web SDK stream — and Data 360 automatically creates a DLO to receive it. The DLO’s columns mirror the source’s columns. Its job is to be a stable, queryable copy of the raw data. It answers one question: what arrived, and from where?

A Data Model Object (DMO) is where that raw data is reshaped into a canonical model — a standard vocabulary Data 360 understands. The DMO conforms to a schema, usually one of the standard objects in Salesforce’s Customer 360 Data Model (Individual, Contact Point Email, Sales Order, Case) or a custom DMO you define. Its job is to give the data meaning the rest of the platform can act on. It answers a different question: what does this mean, and who is it about?

A Data Lake Object is storage; a Data Model Object is meaning. The DLO knows the data came from your e-commerce export. Only the DMO knows that a row is a person, that this column is their email, and that this order belongs to them. Everything downstream reads the meaning, not the storage.

The flow, end to end, is worth committing to memory because every Data 360 problem lives somewhere on it:

Source → Data Stream → Data Lake Object (DLO) → [mapping] → Data Model Object (DMO)
       → Identity Resolution → Unified Individual → Segments / Insights / Agent grounding

Ingestion gets you as far as the DLO. Mapping is the arrow that turns a DLO into a DMO. And everything to the right of that arrow — identity resolution, segmentation, calculated insights, activation, and the semantic layer an agent grounds on — reads the DMO. Skip the mapping and you have data that’s ingested and completely inert.

Why the platform splits them at all

The obvious question: if everything reads the DMO, why not map on ingest and skip the DLO? Because the two layers solve genuinely different problems, and fusing them would break both.

The DLO layer exists so ingestion is decoupled from modeling. Your source systems each have their own idea of what a customer looks like — the CRM calls it Contact, the commerce platform calls it shopper, the loyalty system has a member_id. If ingestion had to conform to a shared schema on the way in, every source change would break ingestion and every new source would be a modeling project before a single row landed. Instead, the DLO catches the data as-is, and modeling happens as a separate, deliberate step you can iterate on without touching the pipe.

The DMO layer exists so the rest of the platform can be built once against a stable vocabulary. Identity resolution doesn’t want to know that this org’s email lives in a column called email_addr and that org’s lives in primary_email. It wants a Contact Point Email DMO with a standard field, every time. The canonical model is what lets Salesforce ship identity resolution, segmentation, and Agentforce grounding that work the same across every customer’s org — because they all target the same DMOs, and the per-org messiness is absorbed in the mapping.

That’s the trade the split buys you: ingest anything in any shape, and still hand the intelligent layers a clean, predictable model. The mapping is where the two worlds meet, which is exactly why it’s where the errors concentrate.

The mapping, and the field that isn’t optional

Mapping a DLO to a DMO is, mechanically, telling Data 360 which DLO field corresponds to which DMO field. Most of it is drag-and-connect. A few decisions in it are load-bearing.

Pick the right DMO category. Every DMO belongs to a category — commonly Profile, Engagement, or Other. Profile objects describe people and things (an Individual, an account); Engagement objects describe time-stamped events (an email open, a purchase, a page view). The category changes the rules: for a DMO in the Profile or Other category, you must map its primary key field, or the mapping won’t save. This is the platform enforcing that every profile record is uniquely addressable. Engagement objects, being event streams, are handled differently. Getting the category wrong is a common cause of a mapping that refuses to save for reasons that aren’t obvious.

Map the primary key deliberately. The primary key is what makes a record unique within the DMO, and it’s not decoration — downstream relationships and identity resolution depend on it being stable and genuinely unique. If your source doesn’t have a clean unique identifier, this is where a formula field earns its place: formula fields let you standardize formatting, concatenate a composite key, normalize a unique identifier, or flag records that meet a condition, all at the DLO level before mapping. A little formula-field discipline here prevents a lot of over-merging later.

Map the identity fields that unification needs. Identity resolution reads the DMO, and it can only match on fields you’ve mapped. Every data stream carrying customer information needs a field mapped that ties it to the Individual DMO — without it, those records simply never participate in unification, and you get the “nothing unifies” symptom with no error to explain it. This is the seam where a modeling shortcut becomes an identity problem, and it’s why conservative match-rule tuning starts with clean mappings, not with the rules themselves.

Let relationships populate — or set them. When you map to standard objects that share a key field, Data 360 populates the relationships between them automatically. For custom DMOs, or cross-object links the platform can’t infer, you set the relationship key yourself. Relationships are what let a segment on one object filter on an attribute of a related object, so a missing relationship shows up later as a filter you can’t build.

Standard DMOs vs. custom DMOs

You have two ways to model, and the right instinct is to reach for the first before the second.

Standard DMOs are the prebuilt objects of the Customer 360 Data Model — Individual, Contact Point Email, Contact Point Phone, Sales Order, Case, and dozens more, many delivered as ready-made data bundles for common sources. Map into these whenever your data fits, because the entire platform is built to understand them: identity resolution knows what an Individual is, activation knows what a Contact Point Email is, and an agent’s semantic model knows what a Sales Order means. Mapping to standard objects is what makes the downstream features work with no extra teaching.

Custom DMOs exist for the data that genuinely doesn’t fit a standard object — a proprietary entity, an industry-specific record with no standard analog. You create one from Data Model → New DMO, set its name, its primary key, and its fields. Custom DMOs are a real and necessary escape hatch, but they carry a cost the standard ones don’t: nothing on the platform understands them out of the box. Every downstream capability that needs to read a custom DMO needs to be told how. The pattern that ages well is standard-first — map to the canonical model wherever the data plausibly fits, and reserve custom DMOs for the genuinely bespoke, so you’re not reinventing Individual under a different name and losing all the machinery that comes free with the real one.

Where data spaces and transforms fit

Two adjacent concepts get tangled with the DLO/DMO split, so it’s worth placing them.

Data spaces are the partition your streams and objects live in — a hard boundary for access and unification, chosen per data stream when you set it up. They sit around the DLO/DMO flow, not inside it: the same modeling applies within each space, but profiles unify within a space, not across. If you run multiple brands or regions, decide the space before you model, because it’s the one boundary that’s expensive to unpick after the fact.

Data Transforms are the heavier reshaping tool for when mapping and formula fields aren’t enough — joining two DLOs, aggregating, or cleaning in ways a field-level formula can’t express. The rule of thumb: use formula fields and mapping for straightforward field-level standardization, and reach for a Data Transform when you need to genuinely restructure data before it becomes a DMO. Both feed the same destination; they’re just different weights of tool for shaping data on the way to the model.

Why the mapping is a data-quality decision, not a config step

The reason this matters beyond passing a certification exam: the mapping is where your data quality becomes the agent’s data quality. Everything downstream inherits the model. A loose primary key over-merges records, and every segment and every agent answer built on the merged profile inherits the error. An unmapped identity field silently drops a whole source out of unification, and your “unified” customer is missing a third of their history. A custom DMO where a standard one would have fit means an agent’s semantic layer can’t reason about the data without bespoke wiring.

This is the same principle behind getting your org AI-ready: AI amplifies whatever sits underneath it, and in Data 360 the thing underneath it is the model. The mapping step is where you decide what your data means, and that meaning propagates — cleanly or messily — into every identity match, every audience, every insight, and every grounded answer an agent gives. It’s the least glamorous screen in the whole platform and the one that most determines whether the platform works.

What to do about it

If you’re standing up Data 360, treat modeling as a first-class phase, not a step inside ingestion. Map into standard DMOs wherever the data fits, and reach for custom DMOs only for genuinely bespoke entities. Get the primary keys right with formula fields before you touch identity resolution, because a clean key is the cheapest over-merge prevention there is. Map the identity fields on every customer-bearing stream, or accept that those records will never unify. And decide your data space boundaries up front, because they wrap everything else.

Then, when a segment comes back empty or an agent can’t find a record, you’ll know where to look first: not at the ingestion, which almost always worked, but at the mapping — the arrow between what arrived and what it means, where Data 360 quietly succeeds or fails.

Understanding the basics

What is the difference between a Data Lake Object and a Data Model Object?

A Data Lake Object (DLO) is where ingested data lands in the shape the source gave it — it’s raw storage, created automatically for every data stream. A Data Model Object (DMO) is where that data is reshaped into a canonical model (usually a standard object like Individual or Contact Point Email) that the rest of the platform understands. The DLO answers “what arrived and from where”; the DMO answers “what does it mean and who is it about.” Identity resolution, segmentation, insights, and agent grounding all read the DMO, not the DLO.

Why is my Data 360 segment empty even though the data ingested?

The most common cause is that the data landed in a DLO but was never mapped to a DMO, or the identity fields weren’t mapped so the records never unified. Ingestion getting you a populated DLO is only half the job — everything downstream, including segments, reads the DMO. Check that the stream is mapped to the right DMO, that the primary key is mapped, and that the identity fields tying it to the Individual object are present.

Should I use standard or custom DMOs?

Standard-first. The Customer 360 Data Model’s standard DMOs (Individual, Contact Point Email, Sales Order, Case, and many more) are understood natively by identity resolution, segmentation, activation, and agent grounding, so mapping into them makes the downstream features work with no extra configuration. Create a custom DMO only for data that genuinely doesn’t fit a standard object — a proprietary or industry-specific entity — because nothing on the platform understands a custom DMO until you teach it to.

---

Standing up Data 360 and trying to get the data model right the first time — or untangling why segments come back empty and profiles won’t unify? Talk to us — a governed, well-modeled Data 360 foundation is the integration work we do.