If you’ve spent a few years as a Sales Cloud admin, you think in objects, fields, and relationships. That’s the whole mental model. What does this Account look like, what stage is this Opportunity in, did this Lead convert?
Then Data 360 shows up with data streams, DLOs, DMOs, and identity resolution, and none of it lines up with the job you actually do. At least not at first glance.
My first week was rough. I expected another cloud. More objects, more tabs, same underlying logic. What I got was a data model built out of things I’d never touched. So the first thing I did was try to map every new term onto something I already knew: DLO equals this, DMO equals that. That approach cost me more time than I’d like to admit, because it’s the wrong one, and I’ll explain why below.
This is the guide I wish someone had handed me that month. What carries over from Sales Cloud, what doesn’t, and where admins keep tripping.
Table of Contents
What is Salesforce Data 360?
Salesforce Data 360 (formerly Data Cloud) is a data platform that sits on top of Sales Cloud and your other systems. It ingests customer data from many sources, unifies it into a single profile through identity resolution, and lets you build insights and segments on top. Your Sales Cloud instincts still help, but it isn’t Sales Cloud with new labels.
The Question You’re Asking Changes
This is the change that took me some time to realize.
In Sales Cloud, you almost always start from a record. The scope of the question is your org. What does our organization know about this customer?
Data 360 pulls that scope way back. Now the question is what the whole company knows. Website visits, support tickets, past purchases, email opens, point-of-sale transactions. Most of that never lived in your Salesforce org. It sits in a marketing platform, a data warehouse, a POS system, a spreadsheet somebody exported once and forgot about.
Data 360’s job is to bring all of that into one place without ripping it out of the systems it already lives in. That’s the real shift, and it isn’t small. You’re not learning a module bolted onto Sales Cloud. You’re looking at data you may have had zero visibility into before.
DLOs and DMOs Are Not Custom Objects
This is where I got called out on an earlier version of this piece, and fairly. I’d leaned on “think of a DMO like a custom object” as a shortcut, and that comparison breaks faster than it helps.
A Data Lake Object (DLO) is where data lands after it’s ingested, in whatever shape it arrived in. If a CSV from your marketing platform has a column called cust_email_addr, that’s exactly what you’ll see in the DLO. Nothing gets cleaned, renamed, or reshaped yet. A DLO is a landing zone, nothing more.
A Data Model Object (DMO) is what you get after mapping raw data to the Customer 360 data model. That’s Data 360’s standard set of objects, things like Individual, Party Identification, and Contact Point Email. They’re the same across every implementation, regardless of industry.
And that’s exactly where the custom object comparison falls apart. A custom object is yours. You define it, and it means whatever your org decides it means. A DMO is standardized on purpose. Data coming from a POS system and data coming from an email platform have to land somewhere comparable, or identity resolution has nothing to work with.
The part that eats admin time isn’t understanding what a DMO is. It’s the DLO-to-DMO mapping itself. You’re deciding, field by field, which source field goes where. And that decision ripples into identity resolution, segmentation, calculated insights, everything downstream. Salesforce clouds usually arrive with mappings already done through what Data 360 calls data bundles. A Snowflake table or a legacy CSV export does not. You map those by hand. Get it wrong early, and it’s expensive to unwind once real volume is flowing.
The Concepts, in the Order I’d Actually Learn Them
I resisted the urge to give you a structured, numbered curriculum, because that isn’t how things made sense to me. But there is certainly a logical sequence, and it matters, because each part builds upon the one before it.
Start with Data Streams. This is just ingestion. How data gets into Data 360 in the first place, whether from a Salesforce cloud, an external system like Snowflake or Amazon S3, or a plain flat file. It’s the least intimidating part. Begin here.
Then DLOs and DMOs, and slow down on the mapping. I mean it. Spend real time here. Mapping decisions are the foundation for everything that comes after, and the mapping step is genuinely the least interesting and most consequential part of the whole platform. That combination is a trap.
Then Identity Resolution. This is match rules and reconciliation rules working together to stitch records into one unified profile, without ever touching the source data. It’s the heart of the platform.
Then Calculated Insights. These are metrics built on your unified data using a query-based logic layer. The closest Sales Cloud comparison is a formula field, and in terms of setup, that’s a decent analogy. The scope is what’s different. A lifetime value insight isn’t pulling from one Opportunity. It’s aggregating Sales Order amounts across every purchase Sarah has made, across every channel. That’s only possible because identity resolution already tied her records together.
Then Segments, last. A ‘segment’ creates a target audience from unified DMO data; it can combine attributes that were not originally part of the same object. I had underestimated the importance of segments in earlier drafts, so let me clarify: this is where the ‘unified profile’ comes into play. However, there is no point in creating one unless you have profiles that are actually segmentable.
Following is the shortcut version of what carries over and what doesn’t.
| Sales Cloud instinct | Does it carry over? | What to know |
|---|---|---|
| Thinking in records and relationships | Yes | Still your best asset for understanding business needs |
| A DMO is like a custom object | No | DMOs are standardized; custom objects are yours to define |
| Identity resolution is like duplicate rules | Partly | Similar mechanics, much higher stakes and volume |
| A Calculated Insight is like a formula field | Mostly | Same idea, but it aggregates across the unified profile |
| Once the connector runs, the data's ready | No | Data isn't usable until it's mapped correctly |
Where This Actually Gets Difficult
The biggest one is treating identity resolution like Salesforce’s duplicate rules.
On the surface, they look alike. Matching logic, configurable rules. But the stakes are higher because you’re working across more sources and far more volume. Loosen your match rules too much, and you merge two different people into one profile. Make them too strict, and the same person splits across several unified profiles, which quietly breaks any Calculated Insight or Segment sitting on top. Quietly is the dangerous word there. Nothing throws an error. Your numbers are just wrong.
There’s no clever way around this. You test your match rules against known duplicate and non-duplicate pairs from your own data before you trust them at scale. That’s the job.
People also underestimate the mapping step, which I keep hammering because it keeps hurting people. Once a connector is running, it’s tempting to assume the data is there and usable. It isn’t. Not until it’s mapped. A disproportionate amount of early implementation time goes here, and most project timelines don’t budget for it.
And please don’t try to resolve identity across every object on day one. Pick the one use case that depends most on an accurate unified profile, one specific customer journey or reporting need, and build and test a ruleset for that first. Prove it works, then expand.
What I Have Seen Go Wrong (and Right) in Practice
The first time I did hands-on work in a real Data 360 org, I got stuck on a basic question. Once we’ve ingested data through data streams and mapped it into a DMO, does the original raw data in the DLO still exist, or does it get overwritten?
It still exists. The DLO keeps holding the raw data even after it’s mapped into a DMO.
That raised a new worry. If we’re pulling data in from an external source and also storing a copy here, aren’t we duplicating storage and driving up cost? That’s how I found Zero Copy federation, which lets you reference and query data where it already lives, in a system like Snowflake or Databricks, without copying it into Data 360 at all. For big external datasets, that changes the math considerably.
I’ve also watched it go wrong. In one org, two completely different customers got merged into a single unified profile because they happened to share a first name and an area code. That was it. The match rule was confirming identity on criteria far too loose to mean anything, and the result was a messy, inaccurate profile that fed straight into reporting. Nobody caught it for a while. That’s the one that made testing match rules feel non-negotiable to me.
Mistakes to Avoid
A short list of the ones I see most, and have made myself.
- Force-mapping every term to a Sales Cloud equivalent. Some things map (an Insight behaves a lot like a formula field). Some don’t (a DMO is not a custom object). Assuming a match where there isn’t one is how you misconfigure identity resolution without realizing it.
- Rushing the DLO-to-DMO mapping. It’s tedious, so people skim it. Then segments and insights are built on a shaky foundation, and the fix is expensive.
- Setting match rules loose “to catch more matches.” Loose rules merge people who aren’t the same person. Test against your own known pairs first.
- Trusting a connector’s output before mapping. Incoming data is not data that is ready for use.
- Boiling the ocean on day one. Trying to unify every object at once instead of proving one high-value use case end to end.
A Sensible Path to Learn It
If you want a route through the official material rather than picking around at random, these three are worth working through in order, hands-on, not just reading:
- Data 360 Learning Journey — a structured, progressive Trailhead path to build a Data 360 foundation from scratch.
- Data 360 Resources — the official Salesforce Help hub covering ingestion, mapping, identity resolution, and more.
- Data 360 Developer Guide — official developer docs for deeper technical implementation.
You Do Not Have to Start from Scratch
Data 360 doesn’t throw away what you know from Sales Cloud. It gives you a bigger space to work in.
The instinct to find a direct equivalent for every term is understandable; I felt it too. But it slows you down and, worse, it obscures where the platform genuinely works differently. Thinking about what a business process truly requires in terms of records, relationships, and data? That mindset remains just as relevant as ever. What’s new is everything happening behind the scenes: taking raw data and structuring it, linking records across systems without altering them, and then leveraging that unified profile at a much larger scale, querying, scoring, and acting upon it.
So here’s your next step, and it’s a small one. Don’t try to learn the whole platform. Open a Data 360 environment, set up a single data stream from a source you already understand, and map it into a DMO by hand. You’ll learn more about how the pieces fit from that one exercise than from a week of documentation, and you’ll hit the mapping questions early, while they’re cheap to get wrong.
Shefali Tanwar
Shefali Tanwar is a 10x Certified Salesforce Professional, Slack Community Chapter Leader, and Salesforce enthusiast with 2+ years of hands-on Sales Cloud experience. She actively leads community initiatives focused on mentoring professionals and helping them transition their core CRM skills into the Data Cloud ecosystem. She is passionate about learning, collaboration, and empowering the Salesforce community.