Salesforce Data 360 (Formerly Data Cloud): What Changed, What It Costs, and What to Fix Before You Implement

Salesforce renamed Data Cloud to Salesforce Data 360 at Dreamforce in October 2025. It is the same product under a new name, and it is the sixth name Data Cloud has carried since 2020. If you are evaluating Salesforce consulting partners right now, expect both names in the same proposal.

Here is what that means for your budget, your architecture, and your existing integration stack.

• Data 360 is Salesforce Data Cloud, renamed. Same license, same data model, same segmentation tools.
• Three capability layers shipped alongside the rename: Intelligent Context, Tableau Semantics, and real-time pipelines.
• Pricing changed materially on March 2, 2026. Three models now exist, and identity resolution dominates the bill.
• Salesforce closed its Informatica acquisition on November 18, 2025. If you already own master data management (MDM) tooling, you may now be paying twice.
• Zero Copy federation reduces your integration surface. It does not remove the need for an integration layer.

The rename is mostly repositioning. The pricing overhaul and the Informatica close are not, and those two should change how you plan your Salesforce roadmap.

What Salesforce Data 360 Is (and What It Is Not)

Salesforce Data 360 ingests, unifies, segments, and activates customer data natively on the Salesforce platform. It resolves identity across disconnected source systems into one unified profile per person or account, then makes that profile available to Sales, Service, Marketing, and Commerce.

What separates Salesforce Data 360 from vendor-neutral customer data platforms is that it is built into the Salesforce metadata framework. Teams reach it through Flow and Agentforce rather than a separate console, which changes who can work with the underlying data model.

Data 360 is also the layer Agentforce agents reason over. Agents deployed without a unified profile run on fragmented context, which is why readiness for agentic AI and readiness for Data 360 are the same conversation.

Data Cloud buyers run into one more clarification before going further. Precisely Data360, written without a space, is a different product from a different vendor. It is an enterprise data governance and catalog suite unrelated to Salesforce.

Both names surface in the same enterprise data conversations. Confusing them will send your vendor evaluation in the wrong direction.

Salesforce also uses “360” across three separate things. Customer 360 is the umbrella name for the connected application suite. Agentforce 360 is the AI platform layer. Data 360 is the data platform underneath both. The product’s original 2020 name was Customer 360 Audiences, which compounds the problem for anyone reading older documentation or a legacy Customer 360 architecture.

Data 360 vs Data Cloud: What Actually Changed

Almost nothing changed functionally in the short term. The license, the data model, the integrations, and the segmentation tools work the way they did under Data Cloud, so existing Salesforce integration work carries over intact.

What changed is positioning. Salesforce moved Data Cloud from “unified customer data platform” to live context that fuels AI, automation, and decision-making across the enterprise. Salesforce Data 360 now sits under the Agentforce 360 umbrella rather than standing alone, which is why agent strategy and data strategy stopped being separate tracks.

Three real capability additions shipped alongside the rename. Intelligent Context connects structured CRM records to unstructured sources including emails, PDFs, and call transcripts. Tableau Semantics establishes unified business metric definitions so the same metric reads identically across every app. Real-time pipelines speed up ingestion and harmonization across clouds and external systems your architecture already depends on.

Vendors covering this rebrand tend to split into two camps: it is only a rename, or it is a total transformation. Neither reading survives contact with the product. The additions are real but incremental, and treating them as either trivial or revolutionary will distort your platform roadmap.

For the record, this product has been renamed six times. The lineage runs Customer 360 Audiences, Salesforce CDP, Marketing Cloud Customer Data Platform, Salesforce Genie, Data Cloud, and now Data 360. Expect internal documentation, vendor proposals, and older integration specs to use at least two of those names.

Under the Hood: Architecture Your Team Should Know

Salesforce Data 360 stores data in a lakehouse built on Apache Iceberg and Parquet, supporting schema evolution, time travel, and high-volume updates. The pipeline is extract, load, transform (ELT) first, which makes data available faster and pushes transformation into your downstream architecture.

Connectivity runs through three paths. Salesforce provides over 270 native connectors, plus application programming interfaces (APIs) and software development kits, plus MuleSoft for everything else. All of it sits on the Data 360 Connector Framework, which handles ingestion, federation, and egress under one architecture.

Zero Copy federation is bidirectional across Snowflake, Databricks, BigQuery, and Redshift. Your warehouse stays where it is, and Data 360 queries it live, which removes a category of data movement work entirely.

Data Spaces organize the platform into domains such as Sales, Service, Marketing, and Support, each carrying consistent semantics, lineage, and policy tags. In practice they function as the silver and gold layers of a medallion architecture, which matters if your data platform strategy already uses that pattern.

This is the point where teams get one thing wrong. Data 360 is not a replacement for Snowflake or Databricks. A warehouse stores history for analysis. Data 360 resolves identity and activates profiles into applications. Treating one as a substitute for the other creates a duplicate storage layer nobody planned for.

Data 360, MuleSoft, and Informatica: What You Now Own Twice

Salesforce completed its acquisition of Informatica on November 18, 2025. The close brought data catalog, integration, governance, quality and privacy, metadata management, and master data management services onto the platform, overlapping directly with capabilities many enterprises already buy from their existing iPaaS vendor.

Salesforce now markets Salesforce Data 360, MuleSoft, and Informatica as one stack under the banner of trusted context. The company cites research that roughly 80 percent of AI projects fail, naming data fragmentation and poor quality as the primary causes, which matches what we see in enterprise data assessments.

The stated trade-off of that vertically integrated model is deeper platform commitment and reduced flexibility to swap components later. That is a reasonable trade for some enterprises and a poor one for others, and the answer depends on what your current architecture already commits you to.

Here is the part most coverage skips. If you already run an integration platform, a data warehouse, and a separate MDM tool, you now have real overlap with a stack Salesforce owns end to end.

The question is not which product is best. The question is what you are paying for twice.

Three questions resolve it. What is authoritative for each data domain today? What capability is now duplicated between your existing tooling and the Salesforce stack? What is contractually locked for the next renewal cycle? Answering those before you configure anything prevents a consolidation exercise from turning into a migration.

One distinction matters throughout this decision. Identity resolution in Data 360 produces a unified profile for activation. MDM produces a governed golden record that is authoritative across the enterprise.

They solve different problems, and one does not replace the other. Enterprises that assume otherwise find the gap when finance and marketing disagree about which customer count is correct, long after the data model is locked.

Data 360 and MuleSoft are similarly complementary rather than competing. Data 360 unifies and activates customer data inside Salesforce. MuleSoft connects applications and governs APIs across everything else. We cover how those boundaries hold up in production in more depth elsewhere.

What Data 360 Costs Under the 2026 Pricing Models

Salesforce introduced a pricing overhaul effective March 2, 2026, addressing long-standing complaints about cost unpredictability. Three models now exist.

The three pricing models

Credit-based consumption charges every operation against a fungible credit pool. Profile-based SKUs price by unified profile, reported in the range of $240 to $420 per 1,000 profiles. Flex Credits span Salesforce Data 360 operations alongside Agentforce actions and AI prompts, so agent rollout plans draw from the same pool.

Flex Credits carry a minimum purchase of roughly 100,000 credits for about $500, with volume tiering that lowers the rate as monthly consumption rises. Sandbox environments consume at a reduced multiplier, typically around 80 percent. Model these against your actual workload before you commit, the same way you would model iPaaS licensing during scoping.

Why identity resolution dominates the bill

Credits are calculated as rows processed divided by one million, multiplied by an operation-specific rate. Those multipliers vary enormously. A data query costs roughly 2 credits per million rows. Identity resolution costs 100,000 credits per million rows, which makes data quality work a direct cost lever.

That single ratio should shape your design. Match rules that are too loose generate reprocessing. Match rules that are too tight generate duplicate profiles and a second unification run. Either mistake is expensive twice, which is why data readiness work belongs before the build, not after it.

The gap between the quote and the invoice

Independent analysis suggests initial vendor quotes commonly land 40 to 60 percent below actual spend. This is not deception. It is what consumption pricing does when neither party knows the usage pattern yet, and the same dynamic shows up in platform licensing generally.

The same analysis recommends planning for two to three times your initial credit estimate across the first six months while consumption patterns settle. It also notes that certified Data 360 specialists remain scarce, with senior consultants commonly billing $200 to $300 per hour on projects running 300 to 600 hours. Budget for the specialist capacity alongside the platform.

Two optimizations worth doing before go-live

Moving non-time-sensitive calculated insights from hourly to daily refresh cuts insight-related credit costs by over 90 percent. Most organizations discover this after the first invoice rather than during design, which is one reason a platform review pays for itself early.

Second, audit which sources actually need ingestion versus federation. Every row you federate instead of ingesting is a row you do not pay to process, and that decision belongs in your integration architecture, not in a later cost review.

Six Things to Fix Before You Start a Data 360 Implementation

Salesforce Data 360 is not plug-and-play. Salesforce Ben’s assessment is blunt and accurate: it demands strategic thinking, technical expertise, and financial awareness, and most internal teams lack the cross-functional experience to get it right on the first attempt. That is the case for bringing in an implementation partner with pattern recognition.

Fix these six before the first configuration session.

1. Define your identity strategy before unification runs

Match rules and survivorship logic determine both profile accuracy and the largest line on your credit invoice. Decide which attributes drive matching, which source wins on conflict, and how households or accounts resolve differently from individuals, then document it as part of your data management practice.

Banks and insurers feel this hardest. Identity resolution across accounts, products, and households is high volume by definition, and a match-rule error carries both cost and compliance consequences. Financial institutions running Financial Services Cloud alongside a unification layer should settle this before anything else.

2. Map your ingestion pattern per source, not per system

Batch, streaming, change data capture, and federation carry different cost and latency profiles. Cataloging your source systems without cataloging the pattern each one requires is the most common planning gap we encounter in enterprise integration work.

The decision framework for this is in the next section. Complete it before you size credits.

3. Audit overlap with tooling you already own

Post-Informatica, your catalog, quality, governance, and master data management capabilities may now exist twice. Decide what is authoritative for each domain before configuring anything, or you will build activation on top of an unresolved ownership question that your enterprise architecture never answered.

This is a consolidation exercise, and it usually pays for itself before the Data 360 build starts.

4. Establish where data can and cannot reside

Salesforce Data 360 runs on Hyperforce, and residency varies by product and by region. Some components and integrations process outside the region where your org lives, which is exactly the detail an auditor asks about during a security and compliance review.

Document a residency position your risk function will sign, whatever jurisdiction you operate in. Include third-party integrations and disaster recovery paths alongside primary storage. Teams that skip this discover the constraint during a security review rather than during design.

5. Assign an owner for credit consumption after go-live

Consumption pricing has no natural owner in most organizations. Platform teams never see the invoice. Finance cannot read the multipliers. The result is a bill nobody predicted and nobody is accountable for, sitting outside your normal managed services reporting.

Name a person before launch, give them access to consumption reporting, and put credit review on the same cadence as your platform monitoring.

6. Be honest about the skills gap

Certified specialists are scarce and expensive, and that is unlikely to change quickly. Decide deliberately between hiring, partnering, and deferring rather than defaulting into an under-resourced build, and apply the same evaluation criteria you would use for any integration partner.

Retail and consumer goods teams often underestimate this. Loyalty, purchase, and service data sits across commerce and marketing systems, and unifying it well requires people who have done it before. The consumer goods architecture patterns are well documented, but documentation is not delivery experience.

When You Need MuleSoft and When Zero Copy Is Enough

Zero Copy is data federation. External sources are queried live without copying into Salesforce, and enriched Salesforce Data 360 output can be shared back without outbound extract, transform, load (ETL). It operates in two modes, query federation and file federation, and both change how you scope integration delivery.

That covers a meaningful share of enterprise data. It does not cover all of it.

The MuleSoft Anypoint Connector for Data 360 handles the patterns federation cannot: streaming ingestion through the Ingestion API for near real-time change data capture, and bulk ingestion for scheduled loads from legacy systems. This is standard MuleSoft delivery work, not a new discipline.

The strongest evidence for the both-and answer is Salesforce’s own build, and it lines up with what we see in multi-platform integration work. Their internal implementation runs Snowflake and an Amazon S3 lakehouse through Zero Copy for federated access, while MuleSoft and Informatica handle ingestion, movement, ETL and ELT, transformation, and data quality.

Salesforce also publishes an interoperability decision guide covering when each pattern applies. Use it alongside your own integration architecture standards.

Use this to sort your sources:

1. Supported warehouse or lakehouse, read access for analytics or profile enrichment. Zero Copy federation.
2. Legacy or on-premise system with no native connector. MuleSoft.
3. Near real-time, record-level change propagation. MuleSoft streaming ingestion through the Ingestion API.
4. Scheduled bulk historical loads. MuleSoft bulk ingestion.
5. Data requiring transformation, validation, or quality checks before it lands. MuleSoft or Informatica, not Data 360.

The point to take away: Zero Copy shrinks your integration surface. It does not eliminate your integration layer. Teams that plan as though it does find the gap during build rather than during design, and a structured integration assessment surfaces it far more cheaply.

Getting Data 360 Right the First Time

Most Salesforce Data 360 problems are architecture problems that surface as invoices. Overlapping tooling, unresolved ingestion patterns, and undefined match rules all show up as credit consumption nobody forecast.

Incepta works across the layers where those problems originate:

• Integration depth. MuleSoft and multi-platform integration for the ingestion patterns Zero Copy does not cover.
• Stack consolidation. Deciding what stays authoritative when Salesforce delivery and existing tooling overlap.
• Post-go-live ownership. A Forward Deployed Engineering model that keeps engineers inside your operating rhythm, which is when consumption patterns actually settle.

If you are scoping a Data 360 build, start by finding out what your current architecture will and will not support. Request a platform assessment.

Frequently Asked Questions