Here’s a hypothetical situation.
- A customer emails your support team on a Tuesday. She is annoyed, and she has reason to be. She placed an order on your ecommerce site nine days ago under a personal email address.
- She updated her marketing preferences last week through a link in a newsletter that went to a different address.
- She is also the named billing contact on her employer’s account, which is where her actual contract sits.
- And she has an open case, raised on the phone, under a slightly different spelling of her surname.
Four systems hold four versions of her. None of them is wrong. None of them is complete. When your service agent, human or AI, opens the record, they see one quarter of a person and answer accordingly.
This is the problem Data 360 exists to solve, and it is worth being precise about it, because the marketing around the product tends to describe outcomes rather than mechanics. This guide covers what Salesforce Data 360 actually is after its latest renaming, how it works step by step, why Zero Copy changes the architecture rather than just the storage bill, what it means for Salesforce Agentforce, and where these programmes quietly go wrong.
Six Names in Five Years, One Unsolved Problem
At Dreamforce in October 2025, Salesforce renamed Data Cloud to Data 360, folding it into the newly announced Agentforce 360 platform. It was, by Salesforce Ben’s count, the sixth name the product has held, after Customer 360 Audiences, Salesforce CDP, Marketing Cloud Customer Data Platform, Salesforce Genie and Salesforce Data Cloud.
It is easy to be cynical about that, and most practitioners were. But the rename has since worked its way into the places that matter: Salesforce’s architect decision guides, the product documentation, and the certification, which became the Salesforce Certified Data 360 Consultant in the Spring ’26 cycle. Expect a transitional period where your contract, your Setup menu and your consultant each use a different word for the same thing. They are the same thing.
What has not changed in six names is the problem. Enterprise customer data is scattered across systems that were never designed to agree with one another, and the scale of that scattering is getting worse rather than better. MuleSoft’s 2026 Connectivity Benchmark Report, a survey of 1,050 IT leaders, found the average organisation now runs 957 applications, of which only 27% are integrated. The application count rose from 897 the previous year. The integration rate did not keep pace.
That gap is the entire market for a customer data platform. It is also, increasingly, the constraint on everything a business wants to do with AI.
Follow One Customer Through Data 360
The clearest way to understand Data 360 is to follow a single customer record through it. There are five moves, and they happen in order.
1. It starts by not moving your data
Data 360 connects to sources rather than demanding them. Native connectors pull from Sales Cloud, Service Cloud, Marketing Cloud and Commerce Cloud. Others stream in from web and mobile SDKs, ingest in batch from cloud storage, or arrive through MuleSoft from systems Salesforce has never heard of. Crucially, data held in Snowflake, Databricks, BigQuery or Amazon Redshift can be queried where it lives, which is the Zero Copy path covered in the next section.
Each source lands as a data stream and is stored, conceptually, in its raw shape. Nothing has been reconciled yet. At this stage you have simply put every version of the customer in the same room.
2. Harmonisation gives every system the same vocabulary
Raw source data is then mapped onto Salesforce’s canonical model, a set of standard Data Model Objects covering the concepts most businesses share: Individual, Account, Order, Case, Engagement. Your ecommerce platform’s cust_email_1 and your service desk’s PrimaryEmail both become the same modelled field.
This step is deliberately separated from the physical data underneath, so that when a source system changes its schema, everything downstream, segmentation, analytics, agents, does not break. It is unglamorous work and it is where most of the elapsed time in an implementation goes.
3. Identity resolution decides who the customer actually is
This is the heart of the product. Data 360 applies match rules, exact matches on email or phone, fuzzy matches on name and address combinations, to determine which records describe the same person. Reconciliation rules then decide, where the matched records disagree, which value wins: most recently updated, most frequently occurring, or a source you have designated as authoritative.
The output is a unified profile. Our annoyed customer from the opening becomes one individual with four linked source records, one current mailing preference, a known employer relationship and a full history. Nothing was deleted. The relationships were simply asserted.
4. Calculated insights turn records into meaning
Once there is a single profile, you can compute against it: lifetime value, engagement recency, product affinity, days since last case, propensity indicators. These are stored as attributes on the profile and refreshed on a schedule, which means downstream consumers ask for a number rather than deriving one. It is the same discipline we describe in designing a decision layer on Salesforce: calculate once, centrally, and let everything else read the answer.
5. Activation and grounding put it to work
Finally, the unified profile leaves the building. Segments activate into Marketing Cloud, advertising platforms and personalisation engines. Profiles surface inside Sales and Service Cloud so that a human sees the whole customer. And, most consequentially in 2026, retrievers expose that data to Salesforce Agentforce so that an agent can ground its reasoning in it.
Zero Copy Is an Architectural Decision, Not a Feature
Zero Copy deserves separating out, because it is routinely described as a convenience and it is not. It is the decision that determines whether Data 360 becomes another copy of your data or a layer over it.
Conventional integration moves data. You extract from Snowflake, you load into the platform, you now maintain two versions, two refresh schedules, two sets of access controls and two opportunities to disagree. Zero Copy instead uses metadata management and query pushdown: Data 360 sends the query to the external engine, that engine executes it, and only the result set comes back. The table never persisted twice.
The scale at which this now runs is genuinely notable. Salesforce’s engineering team has published its work scaling Zero Copy from 1 trillion to 120 trillion rows using file federation, on a lakehouse rebuilt around Apache Iceberg. Federated access at that volume is not a demo feature.
Two practical consequences follow. First, the “do we migrate the warehouse into Salesforce” conversation, which used to stall these programmes for a quarter, is often no longer the right question. Second, and less comfortably, Zero Copy does not exempt you from governance. Federated data still participates in identity resolution and still needs owners, definitions and access rules. You have avoided the copy, not the responsibility.
Agentforce Inherits Whatever the 360 Gets Wrong
Salesforce is unambiguous about the relationship between the two products. Data 360 is positioned as the trusted, unified data layer that gives every agent context, and Agentforce 360 is what consumes it. When Salesforce announced the platform in October 2025, Marc Benioff, Chair and CEO, framed it as connecting “humans, agents, and data on one trusted platform.” The release put 12,000 customers on Agentforce 360.
The more useful description of why this matters came from Rahul Auradkar, EVP and GM of Unified Data Services, Data 360 and AI Foundations at Salesforce, discussing the Informatica integration in December 2025. Without a unified context layer, he said, “AI agents see fragments, whether it’s a batch in manufacturing, an order in commerce, or tickets or a ticket in support.”
Fragments are the failure mode, and they are difficult to detect, which is what makes them expensive. A conventional integration failure is loud: the sync errors, someone gets paged, it gets fixed. An agent grounded in a fragmented 360 fails silently and politely. It tells the customer her order has not shipped, because it can only see one of her two email addresses. It offers a renewal discount she is not eligible for, because the contract sits under the employer account it never linked her to. The answer is fluent, confident and wrong, and nobody finds out until she says so publicly.
This is the foundation-first argument in its most concrete form, and it is why we keep returning to the point that AI starts with data rather than models. The industry data supports it: in the same MuleSoft benchmark, 96% of IT leaders said agent success depends on seamless data integration. Almost nobody disputes the principle. The 27% integration rate tells you how few have acted on it.
Where Data 360 Implementations Quietly Come Apart?
Data 360 implementations rarely fail outright. They stall, deliver a fraction of the intended scope, and get quietly reclassified as phase one. Four causes account for most of it.
Cause 1: It gets bought as a data warehouse
The most common and most expensive misunderstanding. Data 360 is not there to store everything or to replace your analytics estate. Its purpose is resolution and activation. Teams that ingest indiscriminately, on the reasonable-sounding basis that more data is better, end up paying to process records that no segment, insight or agent will ever read.
Cause 2: Match rules end up owned by nobody
Identity resolution is a business decision wearing technical clothing. Deciding that a shared household email does not make two people the same customer, or that a company address should never be a match key, is a policy judgement with revenue and privacy consequences. When it is left to whoever configured the org, the rules drift, duplicate profiles reappear, and trust in the platform erodes faster than anyone rebuilds it. This is the same failure we described in building a single source of truth, arriving one layer higher up the stack.
Cause 3: The consumption model goes unmodelled
Data 360 is priced on consumption. Credits are drawn against the volume of rows processed, weighted by operation, with storage billed separately and monitored through the Digital Wallet. Ingestion from Salesforce’s own applications via native connectors is treated differently from external streaming ingestion, and identity resolution is among the heavier operations. None of that is hidden, and all of it is routinely skipped at business-case stage, because the licence discussion feels like the commercial decision and the refresh schedule feels like a technical detail. It is the other way round.
Cause 4: Governance is deferred to phase two
Data spaces, field-level access, retention, consent, and lineage are treated as hardening work to be done once the value is proven. Then the value is proven, the agent goes to production, and the governance work is now blocking a live customer-facing system rather than a pilot. Deferred governance is simply tech debt with a business case attached.
Get these four right and the payoff is not a dashboard. It is that every subsequent AI initiative starts from a resolved customer rather than a fragmented one, which is the difference between an agent programme that compounds and one that needs re-founding every time it is extended.
Brysa Builds the 360 Before the Agent
The businesses that call us about Data 360 usually describe an agent problem. The agent gives inconsistent answers, or the personalisation is landing on the wrong person, or the pilot demonstrated beautifully and degraded the moment it met real customer records. The agent is where the symptom surfaces. It is almost never where the cause lives.
As a trusted Salesforce consulting partner, we start with the resolution layer, because that is the part of Data 360 nobody can buy their way past. We map which systems hold which version of the customer and which of them should win. We write the match and reconciliation rules as business policy, with named owners, rather than as configuration nobody can explain six months later. We model consumption before the contract is signed, so the refresh schedules and identity runs you are committing to are visible while they are still negotiable. And we decide, deliberately, what stays federated through Zero Copy and what genuinely needs to be ingested.
Only then do we connect Agentforce to it. Not because the agent is the hard part, but because an agent built on an unresolved 360 is a fluent, confident source of wrong answers, and it is far cheaper to prevent that than to explain it to a customer.
We don’t just switch on Data 360. We build the single, governed view of the customer that makes everything downstream of it defensible. If your AI is answering confidently and you are not certain it is answering correctly, the problem is underneath it. Let’s fix that together. Contact us now to talk to our team about your data foundation, or explore our Salesforce consulting services.