**
The Data 360 Operating Model
For decades, the Salesforce “Core” architecture was designed as a robust, monolithic CRM database. It was clear that this legacy approach could not be a perfect solution for big data’s Volume, Velocity, and Variety requirements. Moving to Salesforce Data 360 was a fundamental shift. Fresh tool based on microservices, on top of the Apache Iceberg, brought possibilities to not only provide a comprehensive data lakehouse, but also a perfect context data warehouse for future AI infrastructure.
The Data 360 is still a young, fast-growing product. It cannot be treated as a full Salesforce Platform data warehouse (yet?). Still, it brings new capabilities, from marketing CDP (as it was planned and promoted in the last few years) to a data foundation for AI agents (as it is promoted nowadays).
And it is based on one crucial paradigm that every modern cloud follows.
Disaggregation of Storage and Compute
The most significant architectural departure from the traditional Salesforce Core database (RDBMS) is the complete decoupling of storage and compute resources. In a standard relational database, as your data volume increases, you often face a linear increase in the need for processing power and memory within the same “box.”
In Data 360**, data lives in a persistent storage layer, while compute resources are ephemeral and scale independently.**
Storage Layer
Physical data in Data Cloud does not sit in a proprietary database table. Instead, it is stored in a highly scalable, distributed storage environment (primarily AWS S3).
-
File Format (Apache Parquet) – data is stored in Parquet, an open-source, columnar storage format. Columnar storage is essential for analytical workloads because it allows the system to read only the specific columns needed for a query, drastically increasing speed.
-
Table Format (Apache Iceberg) – to manage these Parquet files at scale, Data Cloud utilizes Apache Iceberg. Iceberg provides a transactional layer on top of the data lake, allowing for “Time Travel” (querying historical versions of data), atomic commits, and schema evolution. This ensures that the data lake remains organized and performant even with petabytes of information.
Compute Layer
Because storage is independent, compute resources are stateless. When a task is triggered, the system spins up a specific compute cluster, executes the logic, and releases the resources. Salesforce orchestrates different engines for different storage tiers:
-
Cold Storage – powered by Apache Spark. This handles massive data processing, ETL, and complex Data Transforms where latency is measured in minutes or more (for batch operations).
-
Warm Storage – powered by Trino. This enables high-concurrency data queries and Zero Copy Federation, allowing you to retrieve data with low latency.
-
Hot Storage – powered by the Hyper engine. This tier materializes data into real-time Data Graphs for low-latency lookups, providing the “instant context” required by Agentforce and Salesforce Personalization.
Metadata Layer
If the data is just files on S3, how does Salesforce know it’s a Customer or an Order? And here comes the Metadata Layer.
The metadata layer acts as the Data Catalog. It stores the definitions, schemas, and mapping logic. When a compute engine is called, the Metadata Layer provides the “map” to the S3 bucket, telling the engine exactly which files to read and how to interpret them.
When a compute engine (Spark, Trino, or Hyper) is invoked, it doesn’t “scan” the data lake blindly. Instead, the Metadata Layer provides a logical-to-physical map. It instructs the engine exactly which file partitions to read and, more importantly, how to interpret those bytes back into structured business objects. This enables so-called Schema-on-Read flexibility, allowing architects to update data models or relationships without needing to physically move or rewrite petabytes of underlying data. That’s why data mapping in Data 360 is free.
This layer introduces a level of abstraction which is a significant shift for someone who comes from traditional systems. For instance, in the “old” Marketing Cloud Engagement, creating a segment or a filtered list usually resulted in the creation of a new physical SQL table (Data Extension).
In Data 360, a segment is often just a metadata definition. When you “query” a segment, the system doesn’t necessarily look at a static list, but it dynamically resolves memberships via the Segment Membership DMO. The segment will become a “physical”, materialized view only if there is a need to send it to a different tool (e.g., Marketing Cloud Engagement), using Activation, and it will be materialized only at the finish stage of sending the activation, by the backend itself, with no access to the “physical” data table from Data 360 user perspective.
By treating data as a virtualized lookup rather than a fixed physical copy, Data 360 ensures that your insights, segments, and AI prompts are always based on the most current state of the data lake. However, this also means that the responsibility shifts from “managing tables” to “managing the integrity of the Metadata logic.”
Data 360 Medallion Architecture
While the disaggregation of storage and compute provides the physical scalability of Data 360, the Medallion Architecture provides the logical discipline. It is a data design pattern used to organize data in a Lakehouse, ensuring that as data moves through the system, it increases in structure, quality, and business value.
What is Medallion Architecture?
The Medallion Architecture is a multi-layered approach to data processing. It categorizes data into three distinct stages: Bronze (Raw), Silver (Harmonized), and Gold (Refined). Each stage represents the next step in making the data more “useful” for the business user.
This pattern has become the industry standard for cloud-native data lakehouses (pioneered by Databricks and adopted by Snowflake/AWS) for several technical reasons:
-
By keeping the raw data (Bronze) alongside the processed data, architects can always trace a business metric back to its source. If a logic error is discovered, you don’t need to re-ingest data, but you re-process it from the Bronze layer.
-
It allows for Schema-on-Read. You can ingest data even if you aren’t 100% sure how you will use it yet. You store it in Bronze and decide on the structure later in the Silver layer.
-
You can leave the Bronze-to-Silver transition (ingestion and cleaning) process for data engineers, while business analysts and AI architects focus on the Silver-to-Gold transition (insights and context).
-
The business users will operate on the Gold layer – using segments, creating reports, and prompting the AI on properly prepared data.
Let’s look at the Medallion Architecture in Salesforce’s edition.
Bronze (DLO) - Raw Data
The Bronze layer is the first “visible” data layer in Data 360. Every piece of information coming from a Data Source Object (DSO, the raw materialized view of the imported file stored in the backend) is written into a Data Lake Object (DLO). At this stage, you aren’t worried about cleaning or formatting. You want a 1:1 mirror of the source system in the data format supported by Data 360, whether that’s Sales Cloud, an S3 bucket, a website stream, or csv file of an Excel master database from our marketing department.
There are three reasons why this “messy” layer is architecturally critical:
-
Because the data is untouched, it serves as the ultimate audit trail. If a customer’s phone number looks wrong in a final profile, you can look at the Bronze layer to see exactly what was sent by the source system.
-
DLOs are essentially immutable snapshots. If you realize three months from now that your mapping logic in the Silver layer was wrong, you don’t need to re-ingest everything from your external systems (which might be expensive or impossible). You simply point your transformations back to the Bronze layer and re-process.
-
Following the Schema-on-Read, you can land data in Bronze even if you aren’t 100% sure how you’ll use it yet. It sits there in its raw state until you’re ready to define its purpose in the layers above.
Why do you put Data Lake Objects in the Bronze layer, if you also have the backend Data Source Objects as the “real” raw data? DSOs are temporary and are not used in the system despite being a bridge between the source and the Data 360 data lake. From an engineer’s point of view, DSOs could be the bronze layer, DLOs will be the silver layer, and DMOs will be the gold layer. But with this approach, theoretically “refined and business-ready” DMOs could have duplicate records (you still have not unified them), and that is fine in some cases, e.g., if you base our implementation only on Individuals, but not if you want the Unified Individuals.
In short, Bronze is your foundation. It’s the base of materialized views with a proper data format, which you can transform and then map into the silver layer.
Silver (DMO) - Harmonized Data
The Silver layer is where raw DLO data is transformed and mapped into Data Model Objects (DMOs). “Data Lake” becomes the “Data Lakehouse” in this layer.
In a typical enterprise, you might have “Customer” data coming from five different systems, each with different field names like Customer_ID, SubscriberKey, or Contact_Number. The Silver layer fixes this by using the Canonical Data model, which provides the standardized Data Model Objects – virtual views of mapped data from Data Lake Objects.
Let’s take an Individual DMO. As a standardized DMO to store people from multiple sources, you ensure that Customer, Lead, Subscriber, E-commerce account, and website users (which were in different Data Lake Objects in the Bronze layer) are separate Individuals, but now mapped into one standardized Data Model Object.
In the Silver layer, you also define how objects relate to one another (e.g., this Individual is connected with this Account). Unlike a traditional SQL database, these relationships in Data Cloud are metadata-driven, allowing for huge flexibility when the business logic changes.
Gold - Unified and business-ready Data
The Gold layer is the finish line of the Medallion process. While Silver gives us clean, harmonized data, Gold is where you actually turn that data into something our business (and our AI) can use.
In the Gold layer, you focus on three main pillars that make the data “ready for business”:
-
Unified Profiles (Identity Resolution) – the outcome of the Identity Resolution engine. If you have a “Szymon Lewandowski” in Sales Cloud and a “Szymon Lewandowski” in your e-commerce system, the Gold layer is where they finally merge into a single “Golden Record”, of course, if there is any additional indicator, such as exact email or other match rule that you applied. By using Match and Reconciliation rules, the system creates a Unified Individual with a Unified Individual Id, giving you what Salesforce is calling “customer 360-degree view”.
-
Calculated Insights (CI) – materialized views with calculated metrics, such as Lifetime Value (LTV) or churn risk. You can use them in reports, segments, or CRM enrichments.
-
Data Graphs – arguably the most critical piece for the Marketing Cloud Next and Agentforce. Data Graphs take the Unified Profile (or other DMO) and materialize it into a JSON schema with related attributes from other DMOs. E.g., you can create a view of Unified Individual with the latest Orders, Cart Items, and Service Cases. Because these views are stored in the hot storage tier, the system can grab the full context of a customer in milliseconds.
From an architecture perspective, the Gold layer is our context engine. This is the layer that business operates on, using Segments, Activations, Data Shares, Reports, Flows, Prompts, and Enrichments.
Data 360 Tech Stack
Under the hood, Data 360 is actually a collection of powerful AWS tools that Salesforce has “packaged up” and simplified. Basically, Salesforce did the heavy lifting of building a complex big data platform, so you don’t have to. They took industry-standard tools, the kind that usually require a whole team of cloud engineers, and narrowed their focus specifically for CRM, Marketing, and AI tasks. You get the power of a custom AWS stack, but with a familiar UI and no infrastructure headaches.
Here’s how that stack looks across the different areas:
- Foundation stack – Amazon S3 storage, Amazon EKS (Elastic Kubernetes Service) controller, and Amazon EMR (Elastic MapReduce) infrastructure
- Apache Iceberg – table format optimized for big data, provides the Parquet files with a metadata layer, ACID transactions, and snapshot isolation
- Query Engines – Spark (heavy batch processing and real-time streaming operations), Trino (fast interactive queries across data sources), Hyper (fast analytical processing)
- Lucene - used for Identity Resolution fuzzy matching
- Atlas - Salesforce’s reasoning engine used for LLM-related operations
Essentially, Data 360 is “Big Data as a Service”. Someone can say that it is just a configured AWS environment and that Salesforce took a bunch of professional AWS and Apache tools, glued them together with a Metadata layer, and gave us a UI to manage it. You get the power of a custom data lakehouse (but with limitations in terms of what you can do), optimized for the Salesforce platform environment.
For a deeper look into how these AWS services actually work together, check out my article - Inside the Data Cloud Infrastructure
Data 360 Customer 360 Model
To achieve the gold layer from the Medallion Architecture pattern, Data 360 needs a proper logical data model that provides the capacity to bring different data schemas into a format that can be used by the business. Here comes the Cloud Information Model (CIM).
Salesforce loves different names, so you can find sources regarding the Customer 360 Data Model, Canonical Data Model, and Cloud Information Model. While the first term is present and explained in the official documentation, the second term gives us information about the flexibility of the Data 360 model. The third term is probably the most “official” name, and is also present in the Mulesoft architecture. Cloud Information Model is based on the Customer 360 Data Model and was developed as an open-source standard by a consortium, including Salesforce, Amazon, and Genesys.