A structured reference for Data 360 (formerly Salesforce Data Cloud) — ingestion patterns, the DLO/DMO data model, identity resolution, unstructured AI grounding, governance, and multi-org strategy.
Data 360 is Salesforce's unified data platform for ingesting, harmonizing, and activating data at scale. It powers Unified Profiles for identity resolution, AI grounding via RAG for Agentforce, and real-time insights across the Customer 360. This reference covers the full lifecycle from raw ingestion to AI activation.
The four operational phases of Data 360 — formerly Salesforce Data Cloud
Two patterns for getting data into Data 360: move it or query it in place
| Pattern | Data Location | Latency | Best For | Cost Consideration |
|---|---|---|---|---|
| Data Streams (Ingestion) | Copied into Data 360 | Batch / Near Real-Time | Unified profiles, transformations, AI grounding | Storage consumed in Data 360 |
| Query Federation | Stays in source (e.g., Snowflake) | Real-time (compute-bound) | Large datasets, avoid duplication, live queries | Compute cost on source system per query |
| File Federation | Stays in object storage (S3, ADLS) | Near Real-Time | Open table formats, data lake architectures | Storage read costs on source |
| Caching / Acceleration | Temporarily in local cache | Low (cached) | Frequent reads on federated data | Temporary storage + refresh compute |
From raw ingestion to harmonized, queryable objects
CRM_001 from Salesforce + ERP_001 from SAP don't collide| Object Type | Layer | Schema | Purpose |
|---|---|---|---|
| DLO (Data Lake Object) | Raw | Source-native, unmapped | Landing zone for ingested data |
| DMO (Data Model Object) | Harmonized | Customer 360 standard model | Unified, queryable, AI-ready data |
| UDLO (Unstructured DLO) | Raw Unstructured | None (PDFs, HTML, audio) | Reference container for unstructured files |
| UDMO (Unstructured DMO) | Harmonized Unstructured | Grouped by content type | Chunked, vectorized, indexed for AI/RAG |
How Data 360 powers RAG for Agentforce, Prompt Templates, and Einstein AI
Identity resolution, Data Graphs, and three types of Insights
Built for high-volume data processing and complex, historical metric generation. Runs as batch jobs on large datasets — ideal for customer lifetime value, historical purchase frequency, or aggregated segment scores.
Designed for continuous processing of micro-batches in near real-time. Processes data as it arrives in small windows — ideal for updating engagement scores, session activity, or cart abandonment signals.
Calculates metrics from a single record in milliseconds, relying on real-time Data Graphs. Used when a decision must be made the instant a record is created or updated — e.g., next best action at the point of call.
| Insight Type | Processing Model | Latency | Data Dependency | Use Case Example |
|---|---|---|---|---|
| Calculated Insights | Batch | Hours | Full DMO dataset | Customer Lifetime Value, 12-month purchase history |
| Streaming Insights | Micro-batch / Continuous | Seconds–Minutes | Incoming event stream | Real-time engagement score, cart activity |
| Real-Time Insights | Single-record compute | Milliseconds | Real-Time Data Graph | Next Best Action at point of contact |
Data Spaces, access control, masking, and lineage
Logical partitions that segregate data, metadata, and processes — for example by brand or department. Users only access contextually relevant data. Prevents cross-contamination between business units sharing one Data 360 instance.
Manual or AI-assisted application of metadata tags to objects and fields. Enforces governance taxonomies at scale — e.g., tagging fields as PII, GDPR-sensitive, or financial data. Enables automated policy enforcement downstream.
RBAC (Role-Based): Access granted based on user role — e.g., Data Engineer sees all DMOs, Analyst sees only their Data Space.
ABAC (Attribute-Based): Access controlled by data attributes — e.g., a field tagged "PII" is hidden from roles without PII clearance. Enforces object-level, field-level, and row-level security.
Conceals sensitive structured data in real-time without altering its underlying values or breaking relationships. A user without PII access sees ***-**-1234 instead of a full SSN — the data is still usable for joins and aggregations.
A visual relationship graph tracing how data objects connect upstream and downstream. Shows the full journey: source connector → DLO → Transform → DMO → Insight → Activation. Essential for audits, impact assessments, and debugging data quality issues.
One Home Org, multiple Companion Orgs sharing data without separate licenses
Primary Salesforce org
Data 360 licensed here
Central management & provisioning
Hosts Data Spaces
Linked Salesforce org
No separate Data 360 license
Accesses shared Data Spaces
Linked Salesforce org
No separate Data 360 license
Accesses shared Data Spaces
Linked Salesforce org
No separate Data 360 license
Accesses shared Data Spaces
End-to-end data flow from source to AI activation
A national retail chain with e-commerce, 200 physical stores, a loyalty program, and a service contact center wants to unify all customer data to power personalized Agentforce interactions and real-time next-best-action recommendations. This walkthrough applies every Data 360 concept to a concrete architecture decision.
What the retail chain needs and why Data 360 is the answer
Build a Unified Customer Profile that merges online, in-store, loyalty, and service history into a single identity. Use it to:
Choosing ingestion vs. federation per data source based on volume, frequency, and transformation needs
| Source | Pattern | Why This Pattern | Lands in |
|---|---|---|---|
| Salesforce CRM (Service Cloud) | Data Stream | Native connector — data must be unified and transformed into DMOs for identity resolution | DLO → DMO (Individual, Case) |
| Commerce Cloud (e-commerce orders) | Data Stream | Native connector — high-frequency order events need transformation and unification | DLO → DMO (Order, Product) |
| POS System (in-store transactions) | Data Stream via S3 | Legacy system exports nightly CSVs to Amazon S3 — S3 connector ingests into DLOs | DLO → Transform → DMO (Order) |
| Loyalty Program DB | Data Stream | Loyalty IDs are the primary cross-system key — must be ingested for identity resolution | DLO → DMO (Loyalty Member) |
| Snowflake (product catalog + inventory) | Query Federation | Large dataset (5M SKUs) — no need to copy it. Query live for product lookups | Federated (no DLO) |
| Product return policy PDFs | Data Stream (files) | Unstructured files for AI grounding — ingested as UDLOs for chunking and vectorization | UDLO → UDMO |
The Snowflake product catalog uses Query Federation — not ingestion — because it's large, rarely changes, and only needed for ad-hoc lookups. Copying 5M SKUs into Data 360 would waste storage and add ETL overhead with no benefit. Federated queries hit Snowflake directly at query time.
Mapping raw data into the harmonized Customer 360 model
| DLO (Raw) | Source | Transform | DMO (Harmonized) | FQK Key Qualifier |
|---|---|---|---|---|
| crm_contact_raw | Service Cloud | Map name, email, phone to standard fields | Individual | CRM_SF |
| loyalty_member_raw | Loyalty DB | Map loyalty_id, email, tier to standard fields | Individual + LoyaltyMember | LOYALTY |
| ecom_order_raw | Commerce Cloud | Map order_id, customer_id, line items to standard | SalesOrder + SalesOrderProduct | ECOM |
| pos_transaction_raw | S3 (nightly CSV) | Normalize date format, map store_id to location, resolve currency | SalesOrder + SalesOrderProduct | POS |
| crm_case_raw | Service Cloud | Map case subject, status, resolution to standard fields | Case | CRM_SF |
A customer with order ID 1001 exists in both Commerce Cloud (key qualifier ECOM) and the POS system (key qualifier POS). Without FQKs, both records would collide. With FQKs: ECOM_1001 and POS_1001 are globally unique — they can both map to the same Unified Individual after identity resolution without overwriting each other.
Merging 3 records of the same person into one Unified Profile
The identity resolution ruleset for NovaMart runs in order:
When two sources have conflicting values for the same field, reconciliation determines which "wins":
| Source Record | Source Key | Matched Via | Merged Into |
|---|---|---|---|
| CRM Contact — Sarah Chen | CRM_SF_00301 | Email: sarah@novamail.com | Unified Individual UI_sarah_chen_0042 |
| Loyalty Member — S.Chen #LY-44821 | LOYALTY_LY-44821 | Email + loyalty_id in Commerce Cloud | |
| Commerce Customer — sarah@novamail.com | ECOM_CC-9912 | Email exact match |
A Data Graph is configured to pre-join Sarah's Unified Individual with her last 90 days of orders (both online and in-store) and her open cases. This materialized JSON snapshot is what the Agentforce service agent queries in milliseconds when Sarah calls in.
How product return policies and FAQs become RAG-ready knowledge
How NovaMart uses all three insight types for different business decisions
Customer Lifetime Value (CLV) — runs nightly as a batch job across all 12M loyalty members. Aggregates 24 months of order history, calculates average order value, purchase frequency, and return rate. Output stored back to a DMO field (clv_score) on Unified Individual.
30-day Purchase Activity Score — processes every new transaction event within seconds. Maintains a rolling 30-day engagement score that updates as each purchase, return, or browse event arrives. No need to wait for nightly batch.
Next Best Offer — fires in milliseconds when Sarah's inbound call is received. Reads the real-time Data Graph (Unified Profile + recent orders) and calculates the most relevant offer from current promotions based on her purchase history and CLV tier.
Data Spaces, tagging, masking, and access control in practice
NovaMart runs one Data 360 instance (Home Org) shared by multiple business units. Data Spaces partition the data:
The Marketing team cannot query raw POS data — they only see aggregated segments from the Customer Experience space.
Fields tagged as PII at the DMO level:
Individual.email → tagged PII, GDPRIndividual.mobile_phone → tagged PII, GDPRIndividual.date_of_birth → tagged PII, GDPR, HIPAASalesOrder.billing_address → tagged PIIDynamic Data Masking is applied: a Marketing analyst running a query sees s***@novamail.com — the email is usable for matching but not readable. The full value is only visible to roles with PII clearance.
| Role | Data Space Access | PII Fields | Masking Applied |
|---|---|---|---|
| Data Engineer | All spaces | Full access (RBAC) | None |
| Marketing Analyst | Marketing only | No PII clearance (ABAC) | Email, phone masked |
| Service Agent (Agentforce) | Customer Experience | Email + phone visible (needed for contact) | DOB masked |
| Store Manager | Retail Operations | No PII clearance (ABAC) | All PII masked |
End-to-end flow from raw sources to Agentforce response