What is Salesforce Data 360? The platform formerly known as Data Cloud, explained

If you bought Salesforce CDP in 2021, you own the same product Salesforce now sells as Data 360. In between, it was called Marketing Cloud Customer Data Platform, then Salesforce Genie, then Data Cloud. Six names in five years. The renames have been so frequent that Salesforce’s own documentation still uses two of them interchangeably, and buyers can be forgiven for wondering whether anything real sits underneath the branding.

Something real does. Data 360 is the layer that pulls data out of your CRM, your warehouse, your commerce platform, and your support desk; reshapes it into one standard model; works out that the “J. Smith” in your service org and the “Jane Smith” in your marketing list are the same person; and then makes that unified picture available everywhere — segments, dashboards, Flows, and increasingly the AI agents Salesforce wants you to run your business on. Since the October 2025 launch of Agentforce 360, Salesforce has positioned it as the data foundation for the whole platform, not a marketing add-on.

This post walks through what the platform actually does, stage by stage, what the Data 360 rename changed in substance versus branding, and how to decide whether you need it at all.

Six names in five years: the product history that explains the confusion

The lineage matters because it explains both the platform’s strengths and its identity crisis. The product launched in 2020 as Customer 360 Audiences, a fairly conventional customer data platform (CDP) aimed at marketers: unify customer records, build audience segments, push them to email and ad platforms. In 2021 it became Salesforce CDP, and in 2022 Marketing Cloud Customer Data Platform — still, in each case, a marketing tool that happened to sit on Salesforce.

Dreamforce 2022 is where the story turns. Salesforce announced Genie, a rebuilt real-time data layer designed to serve the entire platform rather than just Marketing Cloud — a lakehouse-style architecture handling streaming ingestion at a scale the CDP was never built for. By mid-2023 Genie had settled into the name Data Cloud, and the marketing-CDP framing was quietly retired. The product now ingested telemetry, service transcripts, and warehouse tables, not just campaign data.

Then, as of October 14, 2025, Data Cloud was rebranded to Data 360 — the sixth name — announced alongside Agentforce 360 at Dreamforce. Each rename tracked a genuine repositioning: from marketing CDP, to platform-wide data layer, to the context engine for AI agents. The awkward truth is that the underlying pipeline barely changed across the last three names. If you understand that pipeline, every rebrand becomes legible.

What Data 360 actually does: a six-stage pipeline from raw data to grounded agents

Strip away the branding and Data 360 is a data pipeline with opinions. Everything the platform does falls into one of six stages:

Stage	What happens	Key terms
1. Ingest	Data streams bring data in — batch, streaming, or virtually via zero copy	Data streams, connectors, zero copy
2. Model	Raw data lands in lake objects, then is mapped to a standard model	DLO → DMO, Customer 360 Data Model
3. Unify	Identity resolution links records for the same person across sources	Match rules, reconciliation rules, unified profiles
4. Analyze	Metrics and audiences are computed on unified data	Calculated insights, segments
5. Activate	Results are pushed to the systems that act on them	Activation targets, data actions, Flow
6. Ground	AI agents retrieve unified data and content at runtime	Search index, retrievers, RAG

Stage 1: Ingest — data streams and connectors

Everything starts with a data stream: a connection that continuously ingests data from an enterprise source, whether that’s a Salesforce org, an S3 bucket, a website SDK, or a streaming API. Salesforce ships prebuilt connectors for its own clouds and common external systems, plus an Ingestion API for everything else. Notably, ingesting data through the Salesforce CRM connector doesn’t consume credits — a pricing change that removed the odd penalty for bringing your own CRM data into your own CRM’s data platform.

Stage 2: Model — from DLO to DMO

Ingested data lands in a data lake object (DLO) — a container for the raw data as it arrived, preserving source structure. From there, you map DLO fields into data model objects (DMOs): standardized entities in Salesforce’s Customer 360 Data Model, such as Individual, Contact Point Email, or Sales Order. This mapping step is where “guest” from your commerce platform and “contact” from your CRM both become Individual records with comparable fields. It sounds bureaucratic. It’s the whole point — nothing downstream works without it.

Stage 3: Unify — identity resolution

Identity resolution is the feature that justifies the CDP label. You define a ruleset with match rules and reconciliation rules: match rules decide which records refer to the same person, using exact matching on identifiers like email or fuzzy matching on names and addresses; reconciliation rules decide which value wins when sources disagree — most recent, most frequent, or a source priority order you set. Running the ruleset produces unified individual profiles, with link objects preserving the trail back to every source record. In practice this is where implementations earn or lose their money. Loose match rules merge strangers; strict ones leave duplicates. Expect iteration.

Stages 4 and 5: Analyze, segment, activate

On top of unified profiles, you build calculated insights — multidimensional metrics like lifetime value or satisfaction scores computed across the data model — and segments, audience definitions like “customers with an open case and an order in the last 30 days.” Activation is how any of it leaves the building: segments published to Marketing Cloud or ad platforms, data actions firing webhooks and platform events when conditions are met, data shared back out to warehouses, or unified fields surfaced directly in CRM record pages and Flows. A profile nobody acts on is just storage cost.

Stage 6: Ground — feeding agents (more on this below)

The newest stage, and the reason for the latest rename, is serving all of this to AI agents at runtime. We’ll come back to it.

Zero copy, explained: query the warehouse instead of copying it

The most architecturally interesting part of Data 360 is the part that moves no data at all. Zero copy lets Data 360 treat tables in an external warehouse — Snowflake, Google BigQuery, Databricks and other partners in the Zero Copy Partner Network Salesforce launched in 2024 — as if they were native objects, without ETL pipelines and without duplicating storage. It works in both directions: external data federated into Data 360, and Data 360 objects shared out to the warehouse.

Under the hood there are two federation modes: query federation, where Data 360 pushes queries down to the external system’s compute engine, and file federation, where it reads the underlying storage directly with its own engines. By default federation runs as live query — nothing persisted — with optional caching where features need it.

This matters for a simple reason: most enterprises that would consider Data 360 already have a data warehouse, and the historical objection to CDPs was “we refuse to copy our warehouse into another vendor’s silo.” Zero copy is Salesforce’s answer, and in our experience it’s the feature that changes the conversation with data teams. It also tends to consume far fewer credits than batch-ingesting the same tables, though the exact economics depend on your rate card and query patterns.

What the Data 360 rename changed — and what is just branding

So what actually happened in October 2025? Salesforce announced Agentforce 360 as its “agentic enterprise” platform and folded the data layer into the naming scheme: Data Cloud became Data 360, “the trusted, unified data layer that gives every agent context”. Sales Cloud, Service Cloud and the rest kept their names; the data platform and the AI platform got the 360 badge.

On substance, the honest summary is: same product, new center of gravity. There’s no migration, no new SKU to buy, no changed data model — the developer documentation notes the rebrand and carries on describing the same DLOs and DMOs. Your existing licenses, streams, and rulesets are untouched.

What did ship alongside the rename were two capabilities aimed squarely at agents:

• Intelligent Context — a pipeline for unstructured content. It takes PDFs, contracts, diagrams, and transcripts and processes them into retrievable context, so an agent can answer from a warranty document rather than only from structured fields.
• Tableau Semantics — a semantic layer that standardizes business definitions (what counts as “revenue,” which fiscal calendar applies) across the Customer 360 Semantic Data Model, with interoperability partnerships spanning Databricks, dbt Labs, and Snowflake. If two agents compute the same metric differently, users stop trusting both. This is the unglamorous fix.

The framing shift is real, though. Data 360 is no longer sold as a CDP that happens to help AI; it’s sold as the prerequisite for AI, with segmentation and marketing activation as features rather than the headline.

Grounding Agentforce: why the data platform became the AI platform’s foundation

The rename makes strategic sense once you look at how Agentforce actually works. An agent that answers from the model’s general training is a liability; an agent that answers from your data is useful. The mechanism connecting the two is retrieval-augmented generation, and in the Salesforce stack, RAG runs on Data 360.

The pipeline is concrete: unstructured content is chunked, converted to vector embeddings, and stored in a search index; retrievers query that index at runtime and pull relevant passages into the agent’s prompt, with the Einstein Trust Layer handling masking and audit in between. Structured data reaches agents through the same unified model described above — an agent resolving “where’s my order?” is reading the harmonized profile and order DMOs, not raw source tables. Salesforce ships a quick-start version of this (the Agentforce Data Library) and a fully configurable one for teams that need custom chunking and multiple retrievers.

This is also why agent quality problems are usually data problems. Salesforce said at the Agentforce 360 launch that some 12,000 customers were using Agentforce; the ones getting results are, in our observation, the ones that did the unglamorous DMO-mapping and identity-resolution work first. We’ve written before about what separates production Agentforce deployments from demos — grounding quality tops that list, and grounding quality is a Data 360 question.

Who genuinely needs Data 360 — and who should wait

Here’s the part vendor content won’t tell you: plenty of Salesforce customers don’t need this yet. Data 360 earns its cost when three things are true.

• You have real fragmentation. Customer data spread across multiple systems that genuinely disagree with each other — CRM, commerce, support, warehouse, point-of-sale. If all your customer data already lives in one well-kept org, identity resolution has little to resolve.
• You have a use case that needs unification or scale. Cross-channel personalization, segmentation over event data too large for CRM, real-time signals driving service, or agents that must ground in warehouse data and documents. “A single view of the customer” is not a use case; it’s a slide.
• You can operate a consumption-based platform. Data 360 is priced on credits consumed across ingestion, unification, queries, and activation, tracked in a Digital Wallet. Every unnecessary table you ingest and every inefficient refresh costs money. The failure pattern we see most often is bulk-loading history “just in case,” then discovering the budget went on data nobody segments.

Who should wait? Orgs whose data problems are hygiene problems — duplicates, abandoned fields, broken integrations inside a single org. Data 360 will faithfully unify bad data into a unified bad profile. Fix the source first. Likewise, teams with a mature warehouse and a working composable stack shouldn’t adopt Data 360 by default; the case rests on how much you’ll use the Salesforce-native activation and agent surface, and zero copy means adoption doesn’t have to start with a migration. Scoping this honestly — one use case, measured, before scaling — is most of what a good data and AI strategy engagement is for.

The name will change again — the fundamentals won’t

Betting on Salesforce branding stability is a losing trade; some future Dreamforce will probably rename Data 360 too. What’s stayed constant through six names is the shape of the work, and that’s the durable thing to learn. Data comes in through streams. It lands raw in DLOs and becomes useful when mapped to DMOs. Identity resolution turns scattered records into unified profiles. Insights and segments make the profiles measurable, activation makes them actionable, and — the genuinely new part of this era — retrieval makes them available to agents at the moment of answer.

Read this way, the rename is a useful signal rather than noise. Salesforce is telling you where the platform investment is going: unstructured content pipelines, semantic consistency, runtime retrieval. The CDP-era features aren’t going away, but they’re no longer the argument.

For practitioners, the payoff of understanding this is an edge in every conversation about it. When a stakeholder asks “do we need Data 360 for agents?”, you can translate: do we have the data an agent needs, is it unified enough to trust, and can it be retrieved at runtime? When a vendor deck promises a 360-degree customer view, you can ask which DMOs, matched on what rules, activated where, at what credit cost. The platform rewards people who can see through the name to the pipeline. Now you can.

Understanding the basics

Is Salesforce Data 360 the same thing as Data Cloud?

Yes. Data 360 is the new name for Salesforce Data Cloud, announced with Agentforce 360 in October 2025. The rename changed positioning, not architecture: the same data streams, data lake objects, data model objects, identity resolution, and credit-based pricing apply, and existing licenses carry over. Salesforce’s own documentation notes the rebrand took effect on October 14, 2025 and uses both names during the transition.

What is the difference between a DLO and a DMO?

A data lake object (DLO) is the landing container for ingested data, holding it close to its raw source structure. A data model object (DMO) is the standardized layer created by mapping DLO fields into Salesforce’s Customer 360 Data Model — for example, mapping contacts and commerce guests into a shared Individual object. Identity resolution, segmentation, calculated insights, and agent grounding all operate on DMOs, not DLOs, which is why mapping quality determines everything downstream.

Do I need Data 360 to use Agentforce?

Not for basic agents — Agentforce can ground on CRM data and knowledge articles through a preconfigured data library. In practice, Data 360 is how that grounding scales: it provides the search index, vector embeddings, and retrievers behind retrieval-augmented generation, plus unified profiles and zero-copy access to warehouse data. If your agents must answer from documents, external data, or a consistent cross-system customer picture, you’ll end up using Data 360.

---

Weighing up whether Data 360 belongs in your Salesforce roadmap — or trying to make sense of what you already bought? Talk to us — it’s what we do.