Unified Data Model
The Unified Data Model in Salesforce Data Cloud is the standardized schema that maps incoming customer data from multiple source systems into a common structure that downstream consumers (analytics, segmentation, activation, AI models) can read consistently.
Definition
The Unified Data Model in Salesforce Data Cloud is the standardized schema that maps incoming customer data from multiple source systems into a common structure that downstream consumers (analytics, segmentation, activation, AI models) can read consistently. Source systems vary widely in shape: Salesforce Sales Cloud uses Account and Contact; Marketing Cloud uses Subscriber and Contact; Service Cloud uses Case and Asset; external systems use whatever schema they were built on. The Unified Data Model harmonizes all of this into Data Cloud standard objects (Unified Individual, Unified Contact Point Email, Unified Engagement, etc.) so the rest of the platform sees one consistent picture per customer.
Unification happens through Identity Resolution (matching records across sources based on configurable rules: email match, phone match, deterministic identifier match, fuzzy name match) and through Data Stream mapping (translating each source schema into the standard model). The result is the Unified Profile, the central record that ties every interaction back to one person. The Unified Data Model is the foundation that makes Data Cloud worth the platform investment.
The Unified Data Model in Data Cloud: schema, ingestion, resolution, and activation
What the Unified Data Model standardizes
Data Cloud Unified Data Model defines a set of standard data objects that every Data Cloud implementation populates: Unified Individual (the person), Unified Contact Point Email, Unified Contact Point Phone, Unified Contact Point Address (the contact methods), Unified Engagement (interactions like emails opened, pages viewed, support tickets), and several others. Each source system maps to these standard objects through Data Stream configurations. The model is opinionated about what a customer profile should look like in the abstract; specific industries (Health Cloud, Financial Services Cloud) add specialized standard objects (Unified Patient, Unified Account Holder). The standardization lets analytics, segmentation, AI models, and activation features work against a single schema instead of dozens of source-specific ones.
Data Streams and source-to-target mapping
Each connected source (Sales Cloud Account, Marketing Cloud Subscriber, S3 file, custom REST endpoint) becomes a Data Stream in Data Cloud. The Data Stream configuration declares the source schema (the fields in the source) and the target mapping (which standard object and field each source field maps to). Source fields without a mapping land in extension fields on the standard object. The platform runs the Data Stream on a schedule or near-real-time, ingesting source records and producing standard-object records. Mature implementations review the Data Stream mapping carefully; sloppy mapping (multiple source fields collapsed into the same target field, type mismatches, missing key fields) produces a Unified Profile that does not represent the customer well.
Identity Resolution and how unification happens
Identity Resolution is the engine that links records across sources into a single Unified Individual. The configuration defines match rules: which fields to compare, how strict the comparison must be (exact email match, normalized phone match, fuzzy name plus address match), and what evidence threshold creates a link. The platform runs Identity Resolution as a scheduled job or on-demand, comparing newly ingested records against existing Unified Individuals and either creating new ones or linking to existing ones. Result quality depends heavily on match rule tuning; too strict produces duplicate Unified Individuals for the same person, too lenient produces merged profiles that combine different people. The Identity Resolution rule set is the single most important configuration in Data Cloud.
Calculated Insights and the analytical layer
Calculated Insights are pre-aggregated metrics computed against the Unified Data Model. Examples: total revenue per Unified Individual, average days between purchases, count of support cases in the last 90 days, NPS score per customer segment. The platform computes Calculated Insights on a schedule and stores them on or near the Unified Profile so downstream queries do not have to re-aggregate. Without Calculated Insights, every segmentation query and AI model would scan the full raw data; with them, the queries scan the pre-aggregated layer. Mature Data Cloud implementations build a library of Calculated Insights tailored to the org segmentation and activation use cases. The insight library is a long-term investment that compounds across every downstream workload.
Activation and how the Unified Data Model reaches downstream systems
Activation is the process of pushing data from Data Cloud back into other systems: Marketing Cloud for email and journey targeting, Sales Cloud for sales rep visibility, ad platforms for audience targeting, custom REST endpoints for any other system. Each activation is configured with a source (a Segment in Data Cloud), a target (the downstream system), and a mapping (Unified Data Model fields to target-system fields). The platform exports the matching records on a schedule and updates the target. Activation is where the Unified Data Model returns value: by pushing harmonized customer data to the systems that need it, Data Cloud lifts the operational quality of every downstream workflow that consumes its output.
Data Cloud Schema versus Salesforce Object Model
Data Cloud uses Data Lake Objects (DLOs) and Data Model Objects (DMOs), not the standard Salesforce object model. DLOs hold raw source data; DMOs hold the unified standardized data. The names look similar to standard Salesforce sObjects (UnifiedIndividual maps conceptually to Contact), but they are not the same records and they do not share the same database. Queries against Data Cloud go through SQL (or Data Cloud Query API), not SOQL. This separation matters for licensing, integration architecture, and certification exam questions. Data Cloud is its own platform layer sitting next to core Salesforce, exchanging data through Data Streams (in) and Activations (out), not through native sObject access. Plan integrations accordingly.
Standing up the Unified Data Model in Data Cloud
Standing up the Unified Data Model in Data Cloud is a multi-phase project. The four-step routine covers: connect source systems and configure Data Streams, design and tune Identity Resolution rules, build Calculated Insights for downstream use cases, and configure Activations to push harmonized data back to the systems that need it. Each phase delivers value on its own; mature implementations do all four. Skipping any phase reduces the return on the Data Cloud investment substantially.
- Connect source systems and configure Data Streams
For each source system (Sales Cloud, Marketing Cloud, Service Cloud, S3, custom REST), configure a Data Stream in Data Cloud. The connector handles authentication and schema discovery; the Data Stream configuration declares the source-to-target field mapping. Map each source field to the appropriate standard Data Cloud object field; let extension fields capture source-specific data that does not fit the standard model. Test the Data Stream by running an initial ingestion and inspecting the resulting Data Lake Objects. Iterate on the mapping until the ingested data matches the source records. Document the Data Stream configuration in the Data Cloud runbook.
- Design and tune Identity Resolution rules
In Data Cloud, configure the Identity Resolution ruleset that links records across sources into Unified Individuals. Start with conservative rules (exact email match, exact phone match, exact customer id match) and run the resolution job. Inspect the resulting Unified Individuals: are records that should be linked actually linked? Are records that should not be linked accidentally merged? Iterate the rule set based on the inspection. Add fuzzy match rules carefully; the platform can match Jonn Smith to John Smith but also can match the wrong people if the rules are too lenient. Document the rules and the inspection results.
- Build Calculated Insights for downstream use cases
Identify the metrics downstream consumers (Marketing Cloud journeys, Sales rep dashboards, AI models) need pre-aggregated. Build Calculated Insights for each: total customer lifetime value, average order value, days since last purchase, support ticket count in last 90 days. Configure each insight as a SQL query that aggregates over the Unified Data Model. Schedule the insight to refresh on a cadence that matches the downstream consumption (daily for marketing, near-real-time for service). Test the insights by querying them and comparing against the underlying raw data. Document the insight library so future analysts and admins know what is available.
- Configure Activations to push harmonized data back
For each downstream system that needs Data Cloud data, configure an Activation. Define the source segment in Data Cloud (the subset of Unified Individuals to push), the target system (Marketing Cloud, ad platform, custom REST endpoint), and the field mapping (Unified Data Model to target schema). Schedule the activation to run on a cadence that matches the downstream system needs. Test the activation by running it once and confirming the target system received the expected records with the expected field values. Monitor the activation history for failures. Document the activation in the Data Cloud runbook and identify the business owner.
- Identity Resolution rule tuning is the single most consequential Data Cloud configuration. Too strict produces duplicate Unified Individuals; too lenient merges different people. Iterate carefully.
- Data Cloud uses DLOs and DMOs, not standard Salesforce sObjects. Queries use SQL, not SOQL. This separation surprises developers expecting native sObject access.
- Sloppy Data Stream mapping pollutes the Unified Data Model. Multiple source fields collapsed into the same target field, type mismatches, missing keys all produce a profile that does not represent the customer.
- Calculated Insights run on a schedule, not real time. Downstream consumers that need real-time values may not get them; pick the refresh cadence to match the downstream consumption pattern.
- Activations push to downstream systems but do not own the lifecycle there. If the downstream system goes down, the activation may queue or fail; monitor activation history proactively.
Trust & references
Straight from the source - Salesforce's reference material on Unified Data Model.
- Data Cloud OverviewSalesforce Help
- Identity Resolution in Data CloudSalesforce Help
- Data Streams in Data CloudSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Unified Data Model?
Q2. Why is it needed?
Q3. What does it enable?
Discussion
Loading discussion…