Data 360 has played a central role in Salesforce’s portfolio strategy ever since its inception. Because of its importance, Data 360 has undergone more product renamings in a short time than almost anything else in the lineup. While these changes have both amused and frustrated users, they have also signaled a shift in market positioning. The challenge with this zigzag motion is that each iteration places the platform in a different role in the enterprise system landscape, making it increasingly difficult to say what Data 360 should be used for.
In this article, we explore why Data 360 remains one of the toughest Salesforce products to master and why that is.
Sediments of Product Evolution
With each Data 360 incarnation, something new has been introduced while elements of previous versions have remained. This has created the SaaS equivalent of geological sedimentation.
You can still see layers of a marketing-focused CDP, a business data lakehouse, and a CRM-powered semantic layer within the current version of Data 360. While all this adds versatility, the downside is increased complexity. Complexity naturally leads to difficulty, and this is being felt by customers and partners across the ecosystem.
Customer Data Platform (CDP)
Data 360 began as Salesforce’s response to the already sprawling CDP category. At the time, this both made perfect sense and didn’t. On one hand, Salesforce was well positioned to launch an enterprise-grade CDP, drawing on synergies from the world’s leading CRM and marketing automation platforms.
The marketing connection was clear, as CDPs had seen the most success in that domain. However, the CDP market was rife with unrealistic expectations and genuine interest that, unfortunately, did not translate into budget commitments.
Salesforce entered the market relatively late with its own CDP, but benefited from lessons learned by earlier players. In its early days, Data 360 was a stripped-down marketing CDP with the core capabilities you would expect: data ingestion, transformation and unification, identity resolution, and segmentation and activation.
Its main differentiator was native connectivity to CRM and marketing automation. Where Data 360 initially fell short, however, was in marketing analytics, connectors to external martech and ad platforms, and advanced segmentation capabilities.
Data Lakehouse
As the limits of a pure-play CDP became clearer, Data 360 evolved toward a broader data platform, following the industry shift to enterprise-wide data unification. The introduction of lakehouse-style architecture brought more flexible ingestion, larger data volumes, and support for both structured and unstructured data.
This expanded the platform beyond marketing into operational and analytical use cases, positioning it as a central data foundation rather than just a profiling and activation tool.
While this increased its potential value, it also added technical complexity. Data modeling, governance, and storage considerations became more prominent, requiring a different skill set than traditional CDP implementations.
At the same time, the shift blurred boundaries with existing data platforms – mainly data lakes – raising questions about overlap, integration patterns, and ownership of data pipelines.
Semantic Layer
More recently, Data 360 has been positioned as a CRM-powered semantic layer that helps companies unlock insights hidden away in Salesforce objects, knowledge articles, and external files. This helps bridge the gap between raw data and business context, making the information accessible and usable across Salesforce applications. With this, Data 360 becomes the foundation for semantic search and intelligent retrieval.
However, this layer adds yet another dimension to the platform. Users must now understand not only how data is ingested and stored, but also how it is modeled and interpreted for downstream use. While the promise is a more coherent and intelligent system, the added abstraction further contributes to the overall complexity that defines Data 360 today.
System of Context (for AI)
The latest evolution of Data 360 positions it as a system of context for AI, providing the structured, unified, and business-aware data that intelligent applications depend on. This builds on the semantic layer by ensuring that AI is grounded in a consistent understanding of customers, relationships, and business processes. In practice, this means Data 360 serves as the backbone for AI use cases, enriching prompts, informing automation, and maintaining continuity across interactions.
However, this positioning further stretches the scope of the platform. It is no longer just about data unification or modeling, but about orchestration, context management, and real-time relevance. While compelling in vision, this added responsibility reinforces the central challenge: each new layer increases both the potential value and the difficulty of fully understanding and effectively implementing Data 360.
“Fire and Forget” Platform Development
Diving into Data 360, you quickly encounter a sprawl of capabilities. Each of these served a foundational purpose when first introduced, and most still do today. However, despite their central role, many are not continuously curated and often receive only minimal updates and maintenance as part of Salesforce releases. The growing demand for new AI capabilities overshadows the need for incremental development, it seems.
Below, we explore some of Data 360 features that feel more like an afterthought than a core capability.
Formula Fields
Data 360 has received several updates to its streaming and bulk transformation capabilities. In comparison, the simple option of adding a formula field during data stream setup feels somewhat outdated, almost legacy.
Formulas allow you to create additional fields based on existing data stream fields, operators, functions, and free text. I’ve used them effectively on several occasions, but the point isn’t that the feature isn’t useful. It’s that it doesn’t feel as modern as other aspects of Data 360.
Data Spaces
Coming from a marketing consultant background with experience in both Pardot and ExactTarget, I’ve seen two very different approaches to partitioning customer data. Data 360 seems to have taken the simpler Pardot route.
As with Pardot, it enables you to split data rows based on straightforward filtering logic. If you need a hierarchical approach or more complex partitioning logic, it is possible, but extremely complex to set up and maintain.
Activation Targets
While getting data into Data 360 can happen in mere milliseconds, activating it to external systems is a different story. By default, the publishing schedule of a segment is every 12 or 24 hours. Even with rapid publishing, this is only reduced to 1 or 4 hours.
As a marketing user, you cannot help but feel that Salesforce would prefer you to keep the data inside Data 360 rather than send it elsewhere. But that is where the real marketing magic happens.
Calculated and Streaming Insights
When I first heard about calculated insights in Data 360, I thought, “Awesome! I can work with SQL and build some interesting segments and enrichments.” Unfortunately, this turned out to be true only on paper. For lack of a better word, I find the Data 360 calculated insight editors disappointing. The visual editor is prone to errors and freezing, and applying changes retroactively often requires unravelling the entire process back to the node that needs adjustment.
Unfortunately, the SQL builder is no better. It seems incompatible with most SQL formatters and lacks features such as query structuring or color coding. Even the older Marketing Cloud Query Studio offers a better user experience. As they stand, I tend to avoid calculated and streaming insights whenever possible, only using them when the use case explicitly requires it.
Compromise Between Structure and Flexibility
One of the core tensions within Data 360 lies in the need to balance a flexible data model with the structured metadata of an established CRM system. On one hand, modern data platforms are expected to ingest and model data from virtually any source, in any shape or format.
On the other hand, Salesforce is built on a well-defined object model with hard-coded relationships between objects such as accounts, contacts, and opportunities. Bringing these two worlds together inevitably requires compromise.
Flexibility allows Data 360 to serve a wide range of use cases across marketing, analytics, and AI. However, this same flexibility can create ambiguity when aligning with the rigid structures of CRM data.
Mapping loosely defined external data into tightly governed CRM objects is not always straightforward, and edge cases quickly emerge. As a result, implementations often involve tradeoffs between preserving the integrity of the source data and conforming to the expectations of the CRM.
This compromise is not a flaw in itself, but it does add to the cognitive load for users. Understanding how data should flow between the two requires both technical and functional insight. While the end goal is a unified and coherent data foundation, the path there is rarely linear, and often paved with trial and error.
Summary
Data 360 has been notoriously difficult to position and explain, even to the most tech-savvy business executives. This stems from the sheer versatility and complex history of the platform. Some still view Data 360 primarily as a marketing data prep and orchestration tool.
Others see it more broadly as a capability layer that sits somewhere between data infrastructure and business operations. More forward-looking practitioners place their value in real-time context for AI.
These viewpoints do sometimes intersect, but more often they simply coexist. Ultimately, this is not a bad thing. It reflects the fact that Data 360 has found several established niches where it delivers value. It is a collection of tools, rather than a single, clearly defined capability like Sales Cloud or Service Cloud.
As a Salesforce architect, before planning a solution around Data 360, I find that the first step is always understanding which iteration of the platform the client has in mind.
