What the Model Is

Module 1 in the chapter From the Lake to the Model, chapter 8 of the Data 360 Architect course. Each module stands on its own. Next: Reference Data, One to One

The question this module answers: What is the data model, and why does nothing happen until data is mapped to it?

We’ve brought data in through the streams, it’s landed in the lake, and in chapter 7 we reshaped what needed reshaping. Now comes the step everything after it depends on: the model.

Three layers, three jobs

Here’s how I describe the layers. The data streams are the feeds in from the data sources. The data lake objects are pretty much the pool of data that’s come in, in its original format. And the data model is where you have your more abstracted, genericized model that you’re going to use.

Put another way: the lake objects are the original representation of each source, and the model is what we map to. A pilots file, a CRM org and a feed of flights each land in the lake looking like themselves. In the model, they’re described the same way: a person is an Individual, an email address is a Contact Point Email, wherever it came from.

The Customer 360 Data Model

Salesforce’s model is called the Customer 360 Data Model. Salesforce describes it as “organized into subject areas,” each one “a major business activity, such as customer information, product, or engagement data.” The subject areas on Salesforce’s page include:

• Party: people and accounts, and how to reach them. This is where the Individual and the contact points live (modules 3 and 4).
• Engagement: interactions, such as an email or a call.
• Product, Case, Loyalty, Sales Order and Privacy, each for its own business area.

Each subject area is made of data model objects (DMOs). There are two kinds:

• A standard DMO follows Salesforce’s published schema: it “inherits the name, shape, and semantics” of Salesforce’s definition. Individual, Contact Point Email and Account are standard DMOs.
• A custom DMO is one you create in your org, for data the standard model doesn’t cover. You can also add custom fields to a standard DMO.

Salesforce’s best practice is to look at the standard DMOs first, and only “if gaps are identified, extend standard objects by adding custom fields or create a new custom DMOs.”

Nothing happens until it’s mapped

This is the line that makes the model matter. Salesforce: “Data imported into Data 360 must be mapped to a DMO before it can be used for segmentation, activation, analytics, or any other operation.” And on the mapping page: “Only mapped fields and objects with relationships can be used for Segmentation and Activation.”

So a stream that’s running and a lake object that’s full aren’t enough. Until the data is mapped, identity resolution can’t see it, insights can’t count it, and segments can’t select it. A field you didn’t map isn’t there for any of them.

That’s also why the earlier chapters pushed you to decide so much up front. The dictionary from chapter 3 already says, for each field, which model object and field it goes to. Mapping is where that column gets used.

Two kinds of mapping

In my own org, the data went to the model in two different ways, and this chapter follows both.

Reference data, one to one. Airports and runways aren’t about a person. They’re reference data, so I didn’t need to map them to the standard data model objects. I created custom ones from the lake objects, exact representations, field for field. That’s module 2.

People data, into the standard model. The pilots file is about people, so it goes into the standard objects: the Individual, and the contact points for each email and phone. And when I brought in contacts from my CRM org, the same thing happened. There is no concept of contact; there’s the individual. That’s modules 3 and 4.

The difference matters downstream. Identity resolution, segments and activations work on the standard people objects. Reference data supports them: it describes the flights and the airports, but it isn’t who you’re unifying.

What’s built on the model

Everything in Part 2 runs on the model:

• Identity resolution (chapter 9) unifies the Individuals from every source.
• Insights (chapter 10) calculate over the model objects.
• Segments and activation (chapter 11) select from them and send them out.

And one more structure is built from the model: the data graph. Salesforce: “A data graph brings together structured data from your Data Model Objects (DMOs).” You pick one primary DMO, usually a profile object such as the unified individual, and related objects, and Data 360 flattens them into “a single, read-only data graph record,” a JSON document per person. Because it’s “preprepared,” queries return “almost instantly,” and real-time data graphs are what real-time identity resolution, insights and segmentation run on. Chapter 13 covers them. For now, the point is that a data graph can only include what’s in the model.

What an architect decides here

• For each source, whether it maps to the standard model (people and the things the business acts on) or one to one into custom objects (reference data).
• Where the standard model has gaps, whether to add custom fields to a standard object or create a custom one.
• Which fields are mapped at all: only mapped fields can be used.

Explore

All checked 2026-11-14.

• Customer 360 Data Model (opens in a new tab), Salesforce Help: the subject areas, and the full diagram in the Data Model Gallery.
• Data Mapping Best Practices (opens in a new tab), Salesforce Help.
• Data Graphs (opens in a new tab), Salesforce Help.