Thank you to everyone who joined my Dreamforce session. This post recaps that session and our practical journey into Salesforce Data Cloud. It covers the core concepts, the full demo flow, and the exact code you can use to get started.
My goal was to make Data Cloud clear for developers and show how fragmented source data can become a single, unified customer profile that can be queried in real time from custom Apex classes and Lightning Web Components.
The Problem: The Fragmented Customer
We began with a familiar challenge. Our customer, Richard Parker, appears under different identities across systems (“Richard Parker” in Commerce Cloud, “Rich Park” elsewhere) with mismatched IDs and contact details spread across Service Cloud, Marketing Cloud, and external data stores such as Amazon S3.
A simple query like WHERE email = '...' returns only part of his record. To deliver a connected experience, we need to query by person rather than by a single, unreliable identifier.
The Building Blocks: DLOs, DMOs, and the Kitchen Analogy
Before ingesting any data, it helps to understand how Data Cloud organizes information. I like to explain this through a kitchen analogy.
Data Lake Objects (DLOs): The Raw Ingredients — When data arrives from a source system, it first lands in a DLO. Its structure mirrors the source and serves as the staging area—the raw, unprepared ingredients you start with.
Data Model Objects (DMOs): The Finished Dish — DMOs represent the harmonized, business-ready view of your data. They follow a standard, canonical model (for example, Individual, WebsiteEngagement, or ContactPointEmail). This is the finished dish, ready to be served and queried.
Data Streams: The Recipe — A Data Stream is the process that turns those raw ingredients (the DLOs) into the finished dish (the DMOs). It performs the mapping that transforms source data into its unified, usable form.
With these building blocks in place, we can look at how signals move through them to create a unified customer view.
Step 1: Ingesting the Signals
With the concepts established, we began by ingesting Richard Parker’s fragmented identities.
We simulated two e-commerce events arriving through the Ingestion API. Each carried a different user_id and email, representing interactions from separate devices or sessions.
Event Payloads (sent via Postman):
These events were mapped from their DLO to the standard ssot__WebsiteEngagement__dlm DMO.
Step 2: Unifying the Identity with Identity Resolution
This step is the heart of the solution. We demonstrated how two separate source profiles become one unified record.
Ingest Source Profiles
A Contact record from Salesforce and a Customer record from an external system (such as AWS) are each ingested into their respective DLOs.
Map to a Common DMO
Both DLOs are then mapped to the standard Individual DMO. At this point, Data Cloud still treats them as two distinct individuals.
Apply Matching Rules
We configured Identity Resolution with a deterministic rule: Exact First Name + Exact Last Name + Normalized Phone = Same Person.
Create the Unified Individual
Because both source profiles matched this rule, Data Cloud created a single Unified Individual profile. This “Golden Record” receives a stable, unique Unified Individual ID and is linked to all source profiles and their contact points (including both emails).
The result is a single, queryable profile for Richard Parker, which we confirmed with a query in the Data Explorer.
Step 3: Querying the Unified Profile from Apex and LWC
Now for the practical application: consuming this unified data in a custom component.
A. Resolving the Unified ID in Apex
First, we created a cacheable Apex method to retrieve the Unified ID for the Contact record page in view. It uses the ConnectApi.CdpQuery.queryAnsiSqlV2 method to run ANSI SQL against the UnifiedIndividual__dlm.
Java
// DataCloudIdentityService.cls
public with sharing class DataCloudIdentityService {
@AuraEnabled(cacheable=true)
public static String resolveUnifiedIdForContact(Id contactId) {
if (contactId == null) return null;
// Query the UnifiedIndividual DMO using the Salesforce Contact ID
String sql = 'SELECT u.ssot__Id__c FROM UnifiedIndividual__dlm u ' +
'WHERE u.ssot__ExternalRecordId__c = \'' + String.escapeSingleQuotes((String)contactId) + '\' LIMIT 1';
// ... (ConnectApi execution logic) ...
}
}
B. Using a Configurable WHERE Clause
To keep the code flexible, we stored our query logic in a Custom Metadata Type (Data_Cloud_View__mdt). This allows us to modify queries without deploying code. The key field is WHERE_Override__c, which contains a subquery resolving all emails associated with the Unified Profile.
--SQL--
-- In WHERE_Override__c field of the CMDT record
LOWER(Email__c) IN (
SELECT DISTINCT LOWER(uce.ssot__EmailAddress__c)
FROM UnifiedContactPointEmail__dlm uce
WHERE uce.ssot__PartyId__c = '{{UnifiedId}}'
)
How it works:
The LWC calls an Apex controller, passing the
recordId.Apex invokes
resolveUnifiedIdForContactto retrieve the Unified ID.The WHERE clause is retrieved from the Custom Metadata Type.
The
{{UnifiedId}}token is replaced with the actual ID.The completed query runs against
ssot__WebsiteEngagement__dlm, returning events based on all unified emails.
The Lightning Web Component then displays both events for Richard Parker, confirming that we can retrieve a complete interaction history using a single Unified ID—regardless of which email was used in the transaction.
Key Takeaways for Developers
Query by Person, Not Alias: The Unified ID is your stable anchor. Channel identifiers like
user_id or email are just signals that resolve to it.Decouple with Custom Metadata: Storing SQL logic in Custom Metadata Types keeps components flexible and maintainable.
Leverage Derived DMOs: Objects like
UnifiedContactPointEmail__dlm are pre-calculated views that simplify queries and improve performance.Thank you again to everyone who attended the session and followed along with this walkthrough. I hope these examples help you build your own end-to-end Data Cloud integrations with confidence.
Author
Felipe Pradines
Engineering Manager
