12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs
Key Takeaways
- 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.
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.
A service organization wants agents to see every cross-channel order associated with the unified customer directly on the Salesforce Contact record page, without copying order data into CRM storage. Which mechanism should the consultant configure?
An enterprise finance team wants to join Data 360 unified customer and order data against revenue tables that already live in their Snowflake account. They require no duplicate copy of customer data and want Snowflake to bear the query compute. What should the consultant recommend?
A consultant is designing a custom Lightning web component for a contact centre. When an agent opens a case, the component must display that one customer's unified profile, contact points, and related records, returning fast enough to be usable during a live call. Which access mechanism fits the requirement?