Study guide
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs
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
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs
Key Takeaways Explain This Topic AI
Salesforce supports two declarative relationships between DMOs and Salesforce objects: copy fields, which write a scalar Data 360 value onto a CRM record, and related lists of DMOs, which surface a collection of Data 360 records against a CRM record.
Copy field enrichments and Data Cloud-related lists let a service agent see unified context on a Contact or Account page without any code and without exporting the data.
The Query API executes ANSI SQL against DLOs, DMOs, and calculated insights for analytical reads, while the Profile API returns a single unified profile and its related records for interactive lookups.
Data shares publish Data 360 objects outbound to Snowflake, Databricks, BigQuery, and Redshift through zero-copy, so the external platform queries live data instead of receiving a file.
The right access pattern follows the consumption shape: declarative surfacing on a record page uses enrichments and related lists, low-latency application reads use data graphs, analytical reads use the Query API, and warehouse consumption uses data shares.
Last updated: September 2026
12.1 Referencing Data 360 Data from Other Systems
Quick Answer: Data 360 is not a destination — it is a source that other systems read. Salesforce provides a layered set of access mechanisms: copy field enrichments and Data Cloud-related lists surface unified data declaratively on Lightning record pages; data graphs serve denormalized JSON to latency-sensitive applications; the Query API runs ANSI SQL over DLOs, DMOs, and calculated insights; the Profile API returns one unified profile for interactive lookup; Flow and Apex consume Data 360 objects inside automation; and data shares expose Data 360 objects outbound to Snowflake, Databricks, BigQuery, and Redshift with zero copying. The consultant's job is to match the mechanism to the consumption shape.
This is the "Explain how to reference Data 360 data from other systems" objective inside Data Enhancements, Sharing, and Analysis (18%) . Questions are almost always framed as "a user in system X needs to see Y — what should the consultant configure?"
The Two Declarative Relationships Salesforce Supports
Before the APIs, learn the two declarative relationships Salesforce documents between DMOs and Salesforce objects, because they answer the most common scenario type:
Relationship Shape Surfaces As Use When
Copy field One scalar value copied onto the Salesforce record A field on Lead, Contact, Account, or Person Account A single attribute is needed — lifetime value, churn score, loyalty tier, last engagement date
Related list of a DMO A collection of related Data 360 records A related list component on the Lightning record page A history is needed — recent orders, web sessions, cross-channel cases
Both are also the supported grounding relationships for Prompt Builder when you ground a prompt template on Data 360 DMO merge fields, which is why getting them right pays off twice.
Copy Field Enrichments
An enrichment copies a Data 360 attribute onto a CRM record so that ordinary Salesforce features — page layouts, list views, reports, validation rules, flows — can use it as if it were a native field.
Prerequisite: the Salesforce CRM connector must be configured, and the DMO must be related to the target Salesforce object through a mapped identifier.
Behaviour: the value is refreshed by Data 360 on a schedule; it is not a live join. A consultant should say so explicitly when a customer asks for "real-time" — an enrichment is near-real-time, not transactional.
Boundary: enrichments are for scalars. Copying five order records into five sets of flat fields is an anti-pattern; use a related list.
Data Cloud-Related Lists
A related list component renders Data 360 records directly on a Lightning record page — for example every unified order, web session, or subscription associated with the Contact the agent is viewing. Nothing is copied into CRM storage. The agent sees Data 360 data in place, governed by Data 360 permissions and data space scoping.
Data Graphs for Application Access
A data graph is a denormalized JSON object assembled from a primary DMO plus its related objects and calculated insights. Applications that need a whole customer context in a single low-latency read — an agent console, a personalization engine, a mobile app, an Agentforce retriever — read a data graph rather than issuing a multi-table join.
Consultant framing: a data graph is the read model . The canonical DMO layer is normalized for correctness; the data graph is denormalized for speed. Trading storage for latency is the deliberate design choice.
The API Surface
API What It Returns Correct Use
Query API Result sets from ANSI SQL executed against DLOs, DMOs, and calculated insights Analytical reads, validation, data quality checks, integration extracts, backing an internal dashboard
Profile API A single unified individual and its related records Interactive customer lookup from an external portal, contact centre, or custom Lightning component
Ingestion API Nothing outbound — it writes Included here only to be excluded: it is an inbound path and is never the answer to an outbound access question
Connect REST API / Data 360 platform APIs Metadata and administrative operations Automating configuration, CI/CD, and monitoring rather than reading customer data
The most frequently tested distinction is Query API versus Profile API . Both read Data 360. The Query API is a set interface — it answers "how many customers in the Northeast spent over $500 last quarter." The Profile API is a record interface — it answers "show me everything about this one person." Choosing the Query API to power a per-customer service console is the classic wrong answer: it works, but it is the analytical engine doing an interactive job.
Lightning Web Components and Apex
For a bespoke agent console, a Lightning web component backed by the Profile API is the supported pattern for rendering unified profile data inside Salesforce. Flow and Apex can also reference Data 360 objects directly, which is what makes Data 360 data usable inside ordinary platform automation without an integration layer.
Outbound Zero-Copy: Data Shares
Where enrichments and APIs push Data 360 data to Salesforce consumers, data shares expose Data 360 objects to external analytics platforms without moving them. A data share target is created for Snowflake, Databricks, BigQuery, or Redshift, selected Data 360 objects are published into it, and the external platform queries live Data 360 data.
The data never leaves Data 360 storage. The external warehouse holds a reference, not a copy — so there is no pipeline to maintain, no reconciliation drift, and no second copy to secure.
The compute is the external platform's. Cost lands on the warehouse's credits, not only on Data 360.
Governance travels. Data space scoping and object-level controls still apply to what can be published.
Contrast this with an activation to cloud file storage , which writes a physical file of segment members to S3, GCS, or Azure Blob on a schedule. Activation is for operational audience delivery; a data share is for analytical access. A scenario that says "the analytics team wants to join Data 360 customer data with our finance warehouse tables" is a data share, not an activation.
Decision Matrix: Matching the Mechanism to the Requirement
Requirement in the Scenario Correct Mechanism Why Not the Alternatives
Service agent needs one score visible on the Contact page Copy field enrichment A related list is for collections; an API call needs custom development
Service agent needs all cross-channel orders on the Contact page Data Cloud-related list Enrichment flattens scalars only
Agentforce agent needs full customer context in under a second Data graph Calculated insights are batch; joins at request time miss the latency budget
External portal must look up one customer by email Profile API The Query API is the analytical interface
Analyst needs an ad hoc SQL result across DMOs Query API Reports cover governed reporting; the Query API covers exploratory SQL
Finance team needs to join Data 360 data to warehouse tables Data share (zero-copy outbound) Activation produces files and creates a second copy
Marketing needs a member file delivered to an ad platform Activation Data shares are analytical, not operational delivery
Prompt template must reference unified attributes DMO merge fields via copy fields or related lists Retrievers cover unstructured content, not structured merge fields
Exam Traps & Consultant Pitfalls
Trap 1: "Just export it." Any answer that ingests Data 360 data back into CRM as custom objects, or schedules a nightly file to a warehouse, is almost certainly wrong when a zero-copy mechanism exists. Salesforce's design intent is that Data 360 stays the single physical copy.
Trap 2: Enrichment for a history. Copying "Order 1 Date, Order 2 Date, Order 3 Date" onto the Contact is a flattening anti-pattern. Use a related list.
Trap 3: Confusing an activation target with a data share target. Both are configured objects with external credentials, and both appear in Setup. Activation targets receive segment members on a publishing schedule. Data share targets receive object references for querying.
Trap 4: Forgetting that permissions follow the data. Surfacing a related list on a Lightning page does not bypass Data 360 permission sets or data space scoping. A user with no Data 360 access sees an empty component, not an error — which makes this a quiet, frequently misdiagnosed support ticket.