Salesforce Data 360, formerly Data Cloud, is the real-time data engine native to Salesforce that unifies customer data from internal and external systems into single profiles, then makes those profiles available to Salesforce applications, workflows, and Agentforce agents. We implement it at Xavor Corporation as part of our Salesforce development and integration services, and the pattern we see is consistent. Teams scope the Salesforce side carefully and discover that the schedule is governed by systems that sit outside Salesforce entirely.
A Data 360 implementation is scoped in weeks and gated by the state of the systems it connects to.
What changed when Data Cloud became Data 360
Salesforce renamed Data Cloud to Data 360 in October 2025, and the change affects naming rather than architecture. Product pages, developer documentation, and Trailhead modules now lead with Data 360, while most buyers and practitioners still search for Data Cloud.
Salesforce documentation notes that references to the former name persist across materials during the transition. If you are mid-evaluation, expect vendor decks, partner proposals, and training content to use both names for some time.
The rename matters commercially because proposals written before October 2025 describe the same product under a different label, and comparing them requires reading past the branding.
We carry both names through this piece for the same reason.
Customer 360 or Data 360: which one you are buying
Customer 360 is the suite of Salesforce applications your teams work in, and Data 360 is the data engine underneath that assembles what those applications display. The two are frequently quoted in the same sentence and priced as separate decisions.
Sales Cloud, Service Cloud, Marketing Cloud, and Commerce Cloud are where users manage relationships. Data 360 ingests, harmonizes, and resolves records from those clouds and from systems outside Salesforce, then serves unified profiles back into them.
Buying application licenses does not produce unified data, and buying Data 360 does not change what your teams see until the unified profiles are surfaced inside the records they already use.
We cover the unification model in depth in our guide on how Salesforce Customer 360 unifies scattered customer data. This piece assumes that foundation and looks at what implementing it involves.
What has to be true before implementation starts
A Data 360 implementation begins with an honest inventory of where customer records live, which systems can expose them, and whether identifiers reconcile across those systems. Salesforce’s own planning guidance treats data assessment and integration decisions as prerequisites rather than project steps.
Five conditions determine whether a schedule holds:
- Source inventory: every system holding customer records is named, including the ones no team formally owns.
- Queryable interfaces: each source exposes an API, connector, or warehouse endpoint that Data Streams can reach.
- Reconcilable identifiers: the same customer can be matched across systems using fields that exist in all of them.
- A clean Salesforce org: custom objects and legacy configuration map cleanly into standard data model objects.
- Named data owners: someone is accountable for each source when definitions conflict.
The fourth condition catches more programs than the others. Salesforce orgs that accumulated custom objects over a decade often need modernization work before harmonization is practical, which is separate from the Data 360 project and usually discovered inside it.
Published guidance is consistent that unified profile quality depends entirely on the cleanliness of the source data feeding them.
Our work on a Salesforce app modernization using Lightning Web Components started from that position, upgrading a legacy application before anything downstream could rely on it.
Where Data 360 reaches outside Salesforce
Zero-copy architecture lets Data 360 query external data lakes and warehouses such as Snowflake and Google BigQuery without moving or duplicating files, which removes a migration problem and leaves an understanding problem. The data stays where it is. The obligation to know what it means does not.
A warehouse table named customer_master was designed for reporting. An ERP customer record was designed for billing. A PLM product record was designed for engineering change control. None of them was designed to map into a Salesforce data model object.
That mapping is where schedules move. Reconciling a warehouse definition of an active customer against an ERP definition against a CRM definition is negotiation between system owners before it is configuration work.
Every implementation guide currently ranking for this topic is written by a Salesforce specialist, which is why the Salesforce half of the work is well documented and the source-system half is not.
Xavor has integrated enterprise systems for 30 years across ERP, PLM, and data platforms, and our data engineering teams have built reporting estates on Snowflake and Power BI. When we scope Data 360, both sides of the connection are staffed. The integration services that connect Salesforce to other systems cover the mechanics of that layer.
What the eight to sixteen weeks actually contain
Published implementation guidance puts a typical Data 360 project at eight to sixteen weeks, with the range driven by source count, data quality, and how many use cases the first phase carries. Guidance is equally consistent that three to five clearly defined use cases hold a schedule, whereas broader ambitions break it.
The sequence inside that window runs discovery and scoping, ingestion through Data Streams, harmonization into the data model, identity resolution, then segmentation and activation back into Salesforce applications.
Scope discipline moves the timeline more than technical complexity does, because each additional source multiplies mapping decisions rather than adding to them.
The delivery discipline is not specific to Data 360. Xavor ran a phased Salesforce implementation for a large US musical instrument retailer where a clean foundation and a rebuilt three-year account history lifted forecast accuracy from 52% to 84% and shortened the average sales cycle from 47 days to 36. Our guide on aligning a Salesforce implementation with your business processes covers that method in full.
For Data 360 specifically, weigh a partner’s source-system competence alongside Salesforce certifications. We set out the broader criteria for choosing a Salesforce consulting partner.
Grounding Agentforce: what it requires in delivery
Salesforce positions Data 360 as the context layer that grounds Agentforce agents in real-time enterprise data so responses reflect current conditions. Grounding is a data-freshness and access-control requirement before it is a model requirement.
An agent answering a customer question needs the profile to be correct at the moment of the query, the identity resolved to the right person, and the permissions scoped so it surfaces only what that user may see. Each of those is an implementation decision made during harmonization and identity resolution.
Agents inherit whatever the data layer hands them, which makes segmentation logic and match rules part of the agent’s behavior rather than settings underneath it.
We engineered a multi-agent AI chatbot integrated with Salesforce CRM workflows for retail customer support, and the work that determined answer quality sat in how customer context reached the agents at runtime.
What drives Data 360 cost
Salesforce prices Data 360 in two ways, and the choice between them is a decision a buyer makes rather than a default they inherit. Credit-based pricing scales with what the platform does. Profile-based pricing sets a flat rate for predictability.
Under the credit model, the cost sits in the work rather than in the loading. Salesforce states that bringing data into Data 360 is free, including batch ingestion and zero-copy integration, and that charges apply when the data is used. Ingesting from Sales Cloud or Service Cloud through a native connector consumes no credits at all.
Four activities draw down credits:
- Harmonization: mapping and transforming source data into the common model.
- Identity resolution: matching records into unified profiles, which is among the heaviest operations on the rate card.
- Calculated insights and segmentation: every metric and audience that runs, and how often it runs.
- Activation: pushing profiles and segments back out to the systems that use them.
Credits work as a single currency across any Data 360 action, and they transfer between Data 360 and Agentforce, so the same pool covers data work and agent work.
Consumption pricing rewards narrow initial scope, which is the same discipline that protects the timeline.
Three things make this more estimable than it first appears. Salesforce publishes a pricing calculator for modeling expected consumption. Digital Wallet, which is free, reports usage in near real time once you are running, and a monthly usage summary goes to the billing contact. And existing Salesforce customers can provision Data 360 with a limited allocation of storage and credits to test against real data before committing.
Salesforce’s own guidance is worth repeating, because it is more candid than most vendor pricing pages: usage patterns vary significantly between customers and evolve over time, which makes a fixed upfront price difficult to state. Its pricing pages carry a note that they are informational and subject to change, and direct buyers to a sales representative.
The practical consequence for scoping is that the identity resolution decision is a budget decision. How many sources you resolve into unified profiles, and how often you re-run that resolution, moves the number more than the volume of data sitting in storage.
Start with the systems that are not Salesforce
The question that decides a Data 360 timeline is rarely about Salesforce configuration.
It is whether the warehouse, the ERP, and the commerce platform can agree on who a customer is, and whether anyone owns that answer today. Programs that resolve it before scoping finishes close to their estimate. Programs that discover it in week six do not.
Most Data 360 conversations start on the Salesforce side and stall on the source systems. If you want a second opinion on what your estate would need before a scoping call, [email protected] reaches our Salesforce architects and data engineers together.
About the Author
Salman is a Salesforce CRM Consultant and Architecture Lead at Xavor with over 14 years of professional IT experience. Certified in Salesforce and Azure IoT, he designs complex software architectures and delivers high-impact cloud solutions for demanding global hi-tech clients.
FAQs
Yes. Salesforce renamed Data Cloud to Data 360 in October 2025. The product is the same, and Salesforce documentation notes that references to the former name appear across materials during the transition.
Published guidance puts typical projects at eight to sixteen weeks. The range depends on how many source systems connect, how clean their data is, and how many use cases the first phase carries. Three to five use cases is the commonly recommended starting scope.
Customer 360 is the suite of Salesforce applications teams work in. Data 360 is the data engine beneath them that ingests, harmonizes, and resolves records into unified profiles, then serves those profiles back into the applications.
