All insights

Data 360

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

Salesforce's customer data platform is on its sixth name and most buyers have lost the plot. This is what Data 360 does, stage by stage: ingest, model, unify, activate, and ground agents. Plus what the rename changed, what zero copy means, and who needs it.

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

If you bought Salesforce CDP in 2021, you own the product Salesforce now sells as Data 360. In between it was Marketing Cloud Customer Data Platform, then 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. Buyers can be forgiven for wondering whether anything real sits under the branding.

Something real does. Data 360 pulls data out of your CRM, your warehouse, your commerce platform and your support desk, reshapes it into one standard model, and works out that the “J. Smith” in your service org and the “Jane Smith” in your marketing list are the same person.

Then it 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.

Six names in five years

The lineage 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 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. In each case it was 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 whole platform rather than Marketing Cloud alone, with a lakehouse-style architecture that handled 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 retired. The product now ingested telemetry, service transcripts and warehouse tables, rather than campaign data alone.

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 real 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. Once you understand that pipeline, every rebrand becomes legible.

What Data 360 does

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

StageWhat happensKey terms
1. IngestData streams bring data in, by batch, streaming, or virtually through zero copyData streams, connectors, zero copy
2. ModelRaw data lands in lake objects, then is mapped to a standard modelDLO to DMO, Customer 360 Data Model
3. UnifyIdentity resolution links records for the same person across sourcesMatch rules, reconciliation rules, unified profiles
4. AnalyseMetrics and audiences are computed on unified dataCalculated insights, segments
5. ActivateResults are pushed to the systems that act on themActivation targets, data actions, Flow
6. GroundAI agents retrieve unified data and content at runtimeSearch index, retrievers, RAG

Ingest

Everything starts with a data stream, a connection that continuously ingests data from an enterprise source. The source can be 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.

One pricing detail worth knowing: ingesting data through the Salesforce CRM connector doesn’t consume credits. That change removed the odd penalty for bringing your own CRM data into your own CRM’s data platform.

Model

Ingested data lands in a data lake object, or DLO, a container for the raw data as it arrived, preserving the source structure. From there you map DLO fields into data model objects, or DMOs: standardised entities in Salesforce’s Customer 360 Data Model such as Individual, Contact Point Email, or Sales Order.

The mapping step is where “guest” from your commerce platform and “contact” from your CRM both become Individual records with comparable fields. It sounds bureaucratic. That mapping is the whole point, and nothing downstream works without it.

Unify

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 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.

Analyse and 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 get published to Marketing Cloud or ad platforms. Data actions fire webhooks and platform events when conditions are met. Data gets shared back out to warehouses, or unified fields show up directly on CRM record pages and in Flows. A profile nobody acts on is storage cost.

Ground

The newest stage, and the reason for the latest rename, is serving all of this to AI agents at runtime. I will come back to it after the two things people ask about most: zero copy and the rename.

Zero copy: query the warehouse instead of copying it

The most interesting part of Data 360 moves no data at all. Zero copy lets Data 360 treat tables in an external warehouse as if they were native objects, with no ETL pipelines and no duplicated storage.

Snowflake, Google BigQuery, Databricks and other partners sit in the Zero Copy Partner Network Salesforce launched in 2024. 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 pushes queries down to the external system’s compute engine. File federation reads the underlying storage directly with Data 360’s own engines. By default federation runs as a live query with nothing persisted, and optional caching where features need it.

This matters for a simple reason. Most enterprises that would consider Data 360 already have a 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 my experience it is 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 rename changed

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: same product, new centre of gravity. There is no migration, no new SKU, no changed data model. The developer documentation notes the rebrand and carries on describing the same DLOs and DMOs. Your licences, streams and rulesets are untouched.

Two capabilities did ship alongside the rename, both aimed at agents.

Intelligent Context is 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 is a semantic layer that standardises business definitions, such as what counts as revenue and 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. The fix is unglamorous and necessary.

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

Why the data platform became the AI platform’s foundation

The rename makes sense once you look at how Agentforce 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 harmonised 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.

Which is 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, from what I have seen, are the ones that did the unglamorous DMO-mapping and identity-resolution work first. I have written about what separates production Agentforce deployments from demos. Grounding quality tops that list, and grounding quality is a Data 360 question.

Who needs it, and who should wait

Plenty of Salesforce customers do not need this yet. Data 360 earns its cost when three things are true.

You have real fragmentation: customer data spread across systems that disagree with each other, such as CRM, commerce, support, warehouse and 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 personalisation, 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 a slide, not a use case.

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 I 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.

Teams with a mature warehouse and a working composable stack should not adopt Data 360 by default either. The case rests on how much you will use the Salesforce-native activation and agent surface, and zero copy means adoption does not have to start with a migration. Scoping that, one use case, measured, before scaling, is most of what a good data and AI strategy engagement is for.

The name will change again

Betting on Salesforce branding stability is a losing trade. Some future Dreamforce will probably rename Data 360 too. What has stayed constant through six names is the shape of the work, and that is 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 retrieval, the new part of this era, makes them available to agents at the moment of answer.

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

When a stakeholder asks whether you need Data 360 for agents, you can now translate the question: do you 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.

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 licences carry over.

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 standardised 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 decides 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 will end up using Data 360.


If you are weighing whether Data 360 belongs in your roadmap, or trying to make sense of what you already bought, talk to us. Sorting that out is a good part of our week.

Keep reading

All insights