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.