Study guide
1.4 Data 360's Foundational Role in Predictive & Generative AI
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
1.4 Data 360's Foundational Role in Predictive & Generative AI
Key Takeaways Explain This Topic AI
Agentforce requires Data 360 to be enabled at minimum — the Agentforce Data Library and the Einstein Trust Layer do not function without it — and requires Data 360 to be implemented for genuine customer-360 grounding.
A data graph is a denormalized JSON object built from a primary DMO, its related objects, and calculated insights, and it exists to serve low-latency retrieval for personalization, real-time segmentation, and prompt grounding.
Data 360 ingests unstructured content into unstructured data model objects, chunks it, generates vector embeddings, and exposes it through vector, hybrid, or enriched search indexes that retrievers query for retrieval-augmented generation.
Predictive AI in Data 360 runs through AI Models (formerly Einstein Studio), which supports models built from scratch, bring your own model from SageMaker, Vertex AI, or Databricks, and bring your own large language model.
Grounding is a data problem before it is a model problem: an ungoverned, unresolved, unconsented profile produces confidently wrong AI output, which is why Solution Positioning ties AI value directly to identity resolution and consent.
Last updated: September 2026
1.4 Data 360's Foundational Role in Predictive & Generative AI
Quick Answer: Salesforce positions Data 360 as the data foundation underneath its AI portfolio, not as an AI product itself. Generative AI in Salesforce is grounded: a prompt template or an Agentforce agent retrieves real customer context from Data 360 — unified profiles, calculated insights, data graphs , and chunked unstructured content behind a search index — and injects it into the model call through the Einstein Trust Layer . Predictive AI runs through AI Models (formerly Einstein Studio), where a consultant either builds a model from scratch on Data 360 objects or connects an external model with bring your own model (BYOM) . Both paths depend on the same prerequisite: harmonized, identity-resolved, consented data.
The official exam outline places this squarely in Solution Positioning (14%) with the objective "Articulate Data 360's foundational role in generative and predictive AI." It is a positioning objective, which means the questions test whether you can explain why the data platform is the dependency — not whether you can configure a model.
Why AI Fails Without a Data Foundation
A large language model is trained on public text. It has no knowledge of the customer in front of your agent: their open case, the shipment that arrived late last Tuesday, the loyalty tier they were upgraded to this morning, or the fact that they opted out of marketing email in March. Ask it anyway and it produces fluent, plausible, wrong output.
There are three distinct failure modes a consultant should be able to name:
Hallucination from missing context. The model invents an answer because it has nothing real to work from.
Staleness. The model is grounded, but on a nightly extract, so it tells a customer their order is "processing" hours after it shipped.
Fragmentation. The model is grounded on one system's view. The service agent sees three unrelated records for the same person and summarizes only one of them.
Each failure maps directly to a Data 360 capability. Missing context is solved by ingestion and mapping; staleness by streaming ingestion, streaming insights, and real-time data graphs; fragmentation by identity resolution. That mapping — failure mode to platform capability — is the positioning answer the exam is looking for.
Enabled vs. Implemented: The Agentforce Dependency
Salesforce draws an explicit line that appears in scenario questions:
State What It Means What Agentforce Gets
Data 360 enabled Data 360 is provisioned and turned on in the org. No data is connected. The baseline requirement. The Agentforce Data Library and the Einstein Trust Layer do not work at all without Data 360 enabled.
Data 360 implemented Data 360 is enabled, sources are connected, data is mapped to DMOs, and identity resolution rulesets are running. Diverse Customer 360 context, cleansing and transformation, and fully customizable retrieval-augmented generation.
The consultant framing: enabled is a licensing and provisioning prerequisite; implemented is where the business value lives. A customer who says "we turned on Data 360, why is the agent still generic?" has enabled but not implemented.
Grounding and Retrieval-Augmented Generation
Grounding means supplying the model with trusted, current, permissioned data at inference time instead of retraining it. Retrieval-augmented generation (RAG) is the pattern that does it: retrieve relevant records or content chunks, insert them into the prompt, then generate.
Data 360 supplies three distinct grounding surfaces, and picking the right one is a common exam decision:
1. Structured Grounding with DMO Merge Fields
Prompt Builder can ground a prompt template directly on Data 360 DMO fields. Salesforce supports two relationship types between DMOs and Salesforce objects for this purpose:
Copy fields — a Data 360 value physically copied onto a Salesforce record (used for single scalar attributes such as a lifetime value score).
Related lists of DMOs on Salesforce objects — a list of related Data 360 records surfaced against a Salesforce record (used for collections such as recent orders or web sessions).
2. Low-Latency Grounding with Data Graphs
A data graph is a denormalized JSON object assembled from a primary DMO plus its related objects and calculated insights . Rather than making the retrieval layer join a dozen lakehouse tables at request time, Data 360 pre-computes and caches the shape an application needs. The real-time layer of Data 360 uses a Profile data graph for real-time personalization and segmentation, and data graphs are extensible by customers and partners for application-specific shapes.
The consultant heuristic: if the question mentions latency, interactivity, or an agent waiting on a response, the answer involves a data graph. If it mentions analytical depth over history, the answer is a calculated insight.
3. Unstructured Grounding with Search Indexes
Data 360 ingests unstructured content — knowledge articles, PDFs, call transcripts, and also audio, video, and images — maps it to standard DMOs or unstructured data model objects (UDMOs) , splits it into meaningful chunks , and generates vector embeddings . Those embeddings back a search index, and a retriever created in the AI Models tab queries that index on behalf of a prompt template or an agent.
Search Index Type How It Matches Typical Fit
Vector Semantic similarity against embeddings Conceptual questions where the user's wording differs from the source text
Hybrid Semantic similarity plus lexical/keyword matching Content with product codes, part numbers, or policy names that must match exactly
Enriched Builds three chunks — original text, metadata text, and questions the chunk can answer Knowledge bases where recall quality matters more than index size
Predictive AI: The AI Models Workspace
AI Models (formerly Einstein Studio ) is the home for predictive and generative model management inside Data 360. A consultant positions three options:
Build a model from scratch. Clicks, not code. A business user selects a Data 360 object — usually a calculated insight or a DMO shaped as one row per customer — picks the outcome field, and Data 360 trains and scores it.
Bring your own model (BYOM). Connect a predictive model already trained on Amazon SageMaker , Google Cloud Vertex AI , or Databricks . Training happens on the external platform against Data 360 data with no ETL, and predictions flow back into Data 360.
Bring your own large language model (BYOLLM). The same idea extended to generative models hosted externally.
Predictions land back in Data 360 as data, which is the point: a churn score or propensity value becomes an attribute you can filter on in the Segmentation canvas , reference in a calculated insight , consume in a Flow , or surface to a service agent. Salesforce supports both batch and streaming scoring.
Data Preparation Is the Real Work
The recurring implementation pattern — and the correct consultant answer when a scenario asks how to prepare for a predictive model — is:
Unify profiles with identity resolution so one customer is one row.
Use calculated insights and data transforms to flatten history into features (spend in last 90 days, sessions in last 30 days, days since last case).
Produce a clean one-row-per-customer dataset inside Data 360, avoiding external joins and heavy ETL.
Train in AI Models or the external platform, then operationalize the prediction back into segmentation, flows, and agent context.
Governance Does Not Pause for AI
Everything in this section inherits the governance model from Chapter 2 and Chapter 3, and consultants are expected to say so out loud:
Consent still applies. A prediction is a new piece of personal data about a person. A profile that opted out of processing via the Consent API should not be feeding a model or an agent response.
Data spaces still scope access. A model or retriever built in one data space does not silently reach into another.
The Einstein Trust Layer sits between the grounded prompt and the model , applying protections such as data masking and zero data retention with the model provider. It is a control plane, not a data source — and it requires Data 360 enabled.
Exam Traps & Positioning Pitfalls
Trap 1: "Data 360 is an AI product." It is the data foundation. Agentforce, Prompt Builder, and Model Builder are the AI products; Data 360 supplies grounded, governed, resolved data to all of them. Any answer that says Data 360 generates the response is wrong.
Trap 2: Fine-tuning as the fix for wrong answers. When a scenario describes an agent giving outdated or generic answers about a specific customer, the fix is grounding — connect and map the data, build the retriever or data graph — not retraining or fine-tuning a model.
Trap 3: Calculated insight where a data graph belongs. A calculated insight is a scheduled batch aggregation. If the requirement is sub-second retrieval during a live conversation, the right structure is a data graph.
Trap 4: Ignoring identity resolution before AI. Grounding on Individual__dlm rather than UnifiedIndividual__dlm reproduces the fragmentation problem AI was supposed to solve. Unify first.