What Data 360 Is, and Isn't

Module 4 in the chapter Data 360 in One Picture, chapter 1 of the Data 360 Architect course. Each module stands on its own. Previous: A Different Space · Next: Before You Start

The question this module answers: What is Data 360 for, when does data belong in it, and why is it never the system of record?

Two questions come up on almost every Data 360 project. The first is from the business: do we need it? The second comes later, usually from someone who has just seen a unified profile for the first time: can we just make this the master? The answers are yes, sometimes, and no, never. This module is about why. And it starts with a bigger question: what is Data 360 for?

What Data 360 is for

For years, the question was simple: which data do we bring into Salesforce core? Today, data comes from so many different sources: different systems of record, different feeds, events from websites, devices and partners. Sometimes you need to bring all of that in somewhere, link it, transform it, consolidate it, and then take action on very specific things that have happened.

Salesforce core is not the right place to do all of that processing. It’s a shared space, and it has a whole set of limits to keep it fair for everyone in it. Salesforce says so directly about Apex: “Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits so that runaway Apex code or processes don’t monopolize shared resources.” Core is built to run the business one transaction at a time, not to take in millions of rows from a dozen feeds and compute across them.

So what did teams do? Many stood up an external database or another system beside Salesforce, brought the data in there, did the computation, and then had to bring the results back into core. That works, but it’s one more platform to build, run, secure and connect.

That’s the gap Data 360 fills. It started as Salesforce’s customer data platform, a CDP; the Summer ‘23 release notes announced “Customer Data Platform Is Now Data Cloud,” and in October 2025 Data Cloud became Data 360 (module 2). Identity resolution, knowing that five records are one person, is still at the center of it. I don’t want to make it any smaller: that’s why it’s on the happy path in module 1. But Data 360 can do much more than identity resolution:

• Bring many sources together: your orgs, files, databases, data warehouses and event feeds (chapters 4 and 5).
• Transform and consolidate them inside Data 360 (chapters 6 and 7).
• Map them to one model. That’s the power of data model objects. Salesforce’s Customer 360 Data Model is a universal data model; in Salesforce’s words, it “reduces the complexities of integrating data across cloud applications by providing standardized data guidelines.” Salesforce’s list of standard data model objects had 1,566 entries when I counted them in November 2026. So a company doesn’t build every object from the beginning. It starts from the standard model and works only on what’s different about its business: its incremental model (chapter 8).
• Unify, analyze and act on them: identity resolution, insights, segments and actions (Part 2).
• Send the results back: insights, actions and enrichments flow back into your core orgs, and out to marketing and other engines (chapters 11 and 12).

The count is from the Standard DMOs page of Salesforce’s Data 360 DMO and Mapping Guide, which Salesforce marks as a developer preview; a separate page lists 158 older SSOT data model objects. Both lists grow as Salesforce adds objects.

That’s its purpose: many sources in, one model in the middle, and results going back out to where the business works.

The foundation for AI

There’s one more reason Data 360 matters now, and it’s the one you’ll hear about most. AI is only as good as the data you give it. Salesforce’s architects say it directly: “cloud computing and the AI revolution are foundationally changing the data platform architecture.” Data 360 is where Salesforce puts that foundation:

• Grounding. An agent or a prompt that needs to know who the customer is reads the unified profile, built from every source, not one org’s contact (chapters 9 and 19).
• Retrieval over documents. Files and pages become search indexes that agents retrieve from. Salesforce’s guide calls techniques like RAG, retrieval augmented generation, “mainstream drivers of fast and agentic search across the corpus of data” (chapter 18).
• Predictions. Models that score or forecast run on the unified data (chapter 20).
• Memory. The same guide describes agents’ memory “constructed from conversation history” as part of the data platform (chapter 19).

So when an agent gives a bad answer, look at the data first. Names, keys, types and the model, everything in Part 1, are what make an agent’s answers right or wrong.

When data belongs in Data 360

Here’s my test. When you get to a volume of data, a type of data, or a processing of data that you don’t need or want in Salesforce core, then Data 360 can be the place to put it.

Think about what the core org is for. It runs the business transaction by transaction: the opportunity, the case, the order, the contact. It’s built for that, and it’s very good at it. But some data doesn’t fit that shape. Millions of flight events. A pilots file from a partner with fields you’ll use once. Web clicks, device readings, files. You can approach much more volume and many more types of data in Data 360, things you wouldn’t put in your transactional Salesforce core.

And you don’t just store it there. You do the whole mapping and transformation in Data 360, gain the knowledge, and feed it back to your systems. That’s module 1 in one sentence: the pilots file never went into core, but core got back the two facts it needed.

So the question isn’t “should all our data go to Data 360?” It’s “which data has a reason to live in core, and which only needs to send something back?”

Your first use case

So where do you start? Not with all your data. Start with one use case.

Salesforce’s own guidance for planning a project that joins data and AI makes a good checklist. Name the stakeholders: the manager of the people who’ll use it, an executive sponsor, security and legal, and the team that builds it. Then set a goal you can measure, what Salesforce calls a SMART goal (specific, measurable, achievable, relevant and time-bound), with the numbers that will show it worked.

Then work backward. Which data does that one use case need, and does it pass the test above: a volume, a type or a processing core shouldn’t carry? That’s your first set of streams, and nothing more. Module 1’s walk is a first use case in miniature: one question (which pilots have flown ten years or more?), two sources, and two facts back to core.

Why it isn’t the system of record

Now the second question. You’ve unified your customers, the profile looks clean, it has data from five systems. Why not make it the master and edit it there?

Because everything in Data 360 is feed-based. Data comes from a stream and works its way through: the stream, the lake, the model, unification. There’s no simple way to open a record and edit it, the way you would a contact in core. If something is wrong, you fix it where it came from and feed it in again. So by definition, Data 360 is not a system of record. That’s its challenge, and it’s also its design. You need a more persistent store, and that’s the source system.

To be exact about it: Data 360 does let you delete records, and the way it does so makes the same point. You delete through the feed. For a file-based stream, you upload a delete file listing the primary keys to remove; through the Ingestion API, you send a delete request with the keys. The stream has to use upsert, and Data 360 doesn’t cascade deletes: delete a profile, and its related records stay until you delete them too. For data from your core org, the Salesforce CRM connector handles it: when a record is deleted in the source org, it’s removed from Data 360 with the next incremental refresh. Every one of those is a feed operation, not an edit. You change the source, or what you send, and the change flows through.

The same is true of unification. When identity resolution builds a unified profile, it doesn’t change the source records, and it doesn’t update the systems they came from. The originals stay. A unified profile is a view across your sources, not a new master. If you’ve taken the Data Architect course, this is “a map is not a decision” again.

The rule that follows

Every value in Data 360 has a source that owns it. So:

• A correction goes to the source, and flows through again on the next feed.
• An enrichment back to core is a copy, like the years flying in module 1. The source still owns the value; core holds a copy, refreshed from Data 360.
• Know where each value comes from before you build on it. If you can’t name the source system for a field, you don’t know who can fix it.

This is also why I keep saying bring in the data you need to make good decisions. Data 360 is where you bring data together to learn from it and act on it. It isn’t where you keep the one true copy.

Click to enlarge

Fix it at the source. The next feed carries the fix through.

What an architect decides here

• Which processing belongs in Data 360 instead of in core, or in a separate database built beside it.
• Which data has a reason to live in core, and which belongs in Data 360 because of its volume, type or processing.
• Which system is the source for each value you bring in, and who fixes it there.
• What comes back to core as a copy, and how often that copy is refreshed.
• How deletes reach Data 360: through which stream, with which keys, and who runs them.

Beyond the exam: what AI changes. An agent that “updates the customer” can read the unified profile to understand who the customer is. But when it changes something, it has to write to the source system, not to Data 360. Otherwise the change never reaches the system that owns the value.

Explore

All checked 2026-11-14.

• Customer 360 Data Model (opens in a new tab), Salesforce Help.
• Standard DMOs (opens in a new tab), Data 360 DMO and Mapping Guide, Salesforce Developers (developer preview).
• Data Cloud (Formerly Customer Data Platform) (opens in a new tab), Salesforce Summer ‘23 release notes.
• Execution Governors and Limits (opens in a new tab), Apex Developer Guide, Winter ‘27 (API version 68.0).
• Delete Ingested Records in Data 360 (opens in a new tab), Salesforce Help.
• Ingestion API: Delete Records (opens in a new tab), Salesforce Developers.
• Data 360 Architecture (opens in a new tab), Salesforce Architects.
• Kick Off Your AI Project (opens in a new tab), Trailhead, checked 2026-11-14: stakeholders and a measurable goal for a data and AI project.