Everything else on this platform assumes this page.
A seller’s agent can only brief them on what it can read. A marketer’s segment is only as honest as the profile behind it. A service agent answering about an order needs the order. Data 360 is the layer that makes those possible, and its one distinguishing idea is that it reads your data where it already lives — Snowflake, Databricks, BigQuery, S3, Redshift — rather than demanding another copy.
It used to be called Data Cloud, and before that Customer 360 Audiences and Salesforce CDP. If your last proposal used one of those names, this is the same lineage.
The copy problem, and why it is expensive twice.
Nobody planned this either. A warehouse arrived for analysis. The marketing tool needed its own audience store, so data was copied into it. The service tool needed order history, so that was copied too. Each copy was reasonable on the day it was made.
Five copies, five truths
- A warehouse holding the analytical version of the customer.
- A marketing audience store holding a second one, a day behind.
- Order history copied into the service tool, a week behind.
- A spreadsheet somebody maintains because none of those were right.
- Consent recorded in one of them and honoured in none of the others.
- Four answers to “how many customers do we have?”, all defensible.
One resolved profile, read in place
- Live reads against Snowflake, Databricks, BigQuery, S3 and Redshift — no ETL, no duplication.
- Identities matched across devices, channels and anonymous sessions into known profiles.
- Business meaning attached, so a field means the same thing to every team.
- Segments and activation driven from the same profile every application reads.
- Agents grounded in that profile rather than in whatever they were handed.
- Consent and permissions enforced on the path, not re-implemented per tool.
The honest caveat: zero copy is a connection, not magic. Performance and cost still depend on the system at the far end, and some operations will materialise data anyway. Which ones, and what that costs, belongs in an architecture review rather than on a product page — ours included.
Where the data stays, and what moves instead.
Only two things actually travel: the query, and the answer. That is the whole idea, and it is worth seeing drawn once.
If your organisation already runs a lakehouse, that estate is not threatened by this — it is the thing on the bottom row. We write about that side of the connection on our Databricks pages.
Four things sold under one name.
Salesforce groups Data 360 into parts that are bought and used quite differently. Knowing which one a proposal is actually about saves a lot of confusion later.
Headless Data Platform
Zero-copy integration, structured and unstructured data, more than 200 pre-built connectors, and what Salesforce calls context anywhere. This is the plumbing layer, and the connector list matters more here than any feature.
Agent Context Engine
Turns unstructured material — PDFs, call logs, wikis — into structured business knowledge agents can be grounded in, with persistent agent memory, trusted grounding and what Salesforce describes as lower model processing cost. If an AI pilot of yours has disappointed, this is the part of the platform that addresses why.
Customer Data Platform
Unified profiles, identity resolution, personalised journeys and agent-ready data. This is the piece marketers recognise, and the one that was sold as Data Cloud.
Insights, and the rest
An insights builder derives measures such as propensity to buy and customer lifetime value, and low-code tools — Flow, and Agentforce — act on them. Salesforce also lists Data 360 Headless, Agentforce Coworker and Apromore process intelligence in this family.
The setting that quietly decides everything.
Matching identities across devices, channels and anonymous sessions sounds like a technical configuration. It is not. It is a business decision with a privacy consequence, and it is routinely made by whoever happened to be clicking during setup.
Match too tightly — email only — and you under-merge: the same person appears three times, your customer count is inflated, and your personalisation is wrong in a way nobody notices.
Match too loosely — fuzzy name and postcode — and you over-merge, which is far worse. Two real people become one profile. One of them now sees the other’s order history. That is not a data quality issue; it is an incident, and you will hear about it from the customer rather than from a dashboard.
Decide what a customer is
An individual, a household, or an account? Retailers and B2B businesses answer this differently, and the answer changes every number downstream.
Rank your identifiers
A loyalty number is stronger than an email, which is stronger than a name and a postcode. Write the ranking down before you write the rules.
Test against known answers
Take 200 records where you know the truth, run the rules, and count both the merges that should not have happened and the ones that should have.
Decide who owns it
One named person, not a committee and not the implementation partner. Match rules outlive projects.
Re-test when a source joins
Every new system brings new identifier quality. The rules that were right for three sources are not automatically right for four.
How we treat match rules
They get written down in business language, reviewed by someone accountable for customer data, and tested against a sample where the right answer is already known — counting both the merges that should not have happened and the ones that should have. Then they get re-reviewed whenever a new source is connected, because every new system brings different identifier quality and changes the arithmetic.
It is an hour of work a quarter. The alternative is finding out from a customer that they can see somebody else’s order history.
Consumption, in three parts.
Data 360 is not priced per user. Salesforce bills it as consumption credits, data storage and premium add-ons. Existing Data Cloud agreements are honoured to the end of their current term, and existing Salesforce customers can start free.
Credits are where the surprises live, because almost everything interesting consumes them: profile unification, identity resolution, segmentation, activation, and the queries agents make. None of that is unreasonable — but it means the cost of this platform is set by how much data you point at it, not by how many people use it.
The failure mode is predictable. An enthusiastic first scope ingests everything, because storage feels cheap and nobody wants to be the person who left something out. The first full quarter arrives, the number is three times the estimate, and the programme loses its sponsor.
Scope the data to the decisions it serves. If you cannot name the decision a table changes, it does not belong in the first release.
The sentence that has saved our clients the most moneyConsumption credits
Drawn down by the work: unifying profiles, resolving identities, building segments, activating audiences, answering agent queries.
Data storage
What you hold in the platform itself. Zero-copy sources reduce this, which is part of the commercial argument for them as well as the architectural one.
Premium add-ons
The optional capabilities on top. Which ones you need depends entirely on what you are building, and they should be decided after the first release rather than before it.
What can be checked, and what cannot.
Salesforce publishes rather less hard data about this product than about the others, which is itself worth noting. Here is what it does say.
Named customers on its pages include FedEx, Heathrow, Pacers Sports & Entertainment, UChicago Medicine and MIMIT Health. What Salesforce does not publish for this product is any quantified claim — no hallucination reduction figure for the Agent Context Engine, no cost-saving percentage, no match-rate benchmark. We would rather tell you that than fill the gap with something borrowed from a blog.
Where this leads next.
The five are read in any order, but these two are the ones this page leans on most.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What data teams ask us.
Is this a data warehouse? Do we still need ours?
No, and yes. Data 360 is not a replacement for Snowflake, Databricks or BigQuery — it connects to them. Salesforce's own framing is zero copy: it reads live data in Snowflake, Databricks, Google BigQuery and AWS (S3 and Redshift) without ETL or duplication.
What it adds is the thing a warehouse does not: a resolved customer profile, with business meaning attached, that Salesforce applications and agents can act on in the moment. Keep the warehouse for analysis; use this for action.
What does zero copy really mean in practice?
That the query runs against your data where it lives rather than against a copy Salesforce has taken. No extract, no nightly sync to babysit, no second copy drifting out of step with the first, and no second place to govern.
The caveat worth knowing: zero copy is a connection, not magic. Performance and cost still depend on the system at the other end, and some operations will materialise data. Which ones, and what that costs, is a question for your architecture review rather than the product page.
What is the Agent Context Engine?
The part of Data 360 that turns unstructured material — PDFs, call logs, wikis — into structured business knowledge an agent can be grounded in, along with persistent agent memory. Salesforce says this reduces hallucinations and model processing costs, though it publishes no figure for either.
It is the most consequential piece for anyone whose AI pilot disappointed. Most of those failed on retrieval, not on the model: the agent had nothing good to read.
How is it priced?
Consumption, in three parts: Consumption Credits, Data Storage and Premium Add-ons. Existing Data Cloud agreements are honoured to the end of their current term, and existing Salesforce customers can start free.
Credits are where the surprises live. Profile unification, identity resolution, segmentation and activation all consume, and a badly scoped ingestion — everything, because we might need it — produces a bill that ends the project's political support. Scope the data to the decisions it serves.
Does identity resolution actually work?
It matches and resolves identities across devices, channels and anonymous sessions into known profiles — and how well it does that is a function of your match rules, not of the product. Email-only matching under-merges; loose fuzzy matching over-merges, which is worse, because merging two real customers into one profile is a privacy incident rather than a data-quality issue.
We treat match rules as a decision for the business, documented and reviewed, not a default somebody accepted during setup.
Where does it sit against our existing lakehouse work?
Beside it, reading from it. If you are already on Databricks or Snowflake, that estate stays where it is and Data 360 connects to it — which is also why the connector list matters more than any feature.
Salesforce names 200-plus pre-built connectors, and it is named a Leader in customer data platforms by Forrester for B2C and by Gartner for a second year. Both are its own citations, and both are reasonable signals rather than proof.
Checked against Salesforce's own pages in November 2026. Product names and packaging in this area have changed twice in three years; check salesforce.com before you commit.
Tell us the question nobody can answer.
Every organisation has one: how many customers do we actually have, or what did this person buy last year, or did we already email them this week. Bring us that question. Working out why it cannot be answered today maps the data work far better than a requirements workshop does.
- The question, and why it cannot be answered
- Which sources connect live and which must be copied
- Match rules written down and tested
- Credits modelled against your real volumes
- A first release scoped to decisions, not to tables
Salesforce, Agentforce, Data 360, Slack, Tableau, MuleSoft and other Salesforce product names are trademarks of Salesforce, Inc. Other names are the property of their owners. Screens shown are illustrations with sample data. Product descriptions follow Salesforce's own published material and can change, so check salesforce.com for current details.
Our Nevbrook Compass is the name we give to how we handle Salesforce Data 360: one accountable partner, from the first meeting to long after go-live.