9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting

Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting

When an Identity Resolution ruleset is deployed in Salesforce Data Cloud, the platform synthesizes a comprehensive semantic schema known as the Unified Profile Layer. This layer sits above the harmonized Data Model Objects (DMOs) and contains the consolidated representations of individuals, their contact points, and the relational bridges that trace data lineage back to source systems.

Designing, querying, and maintaining this unified layer requires a certified consultant to master the underlying schema architecture, understand how graph re-clustering behaves when source data changes, diagnose identity resolution anomalies, and implement upstream data hygiene governance to prevent catastrophic data corruption.

---

Architecture of Unified Data Model Objects (Unified DMOs)

Deploying an Identity Resolution ruleset automatically generates a specialized family of system-managed Data Model Objects. These objects are designated with the standard Data Cloud physical object suffix __dlm (Data Lake Model / Data Model Object) and prefixed with Unified.

┌─────────────────────────────────────────────────────────────────────────┐
│                     HARMONIZED CANONICAL DMOs                           │
│  Individual__dlm, ContactPointEmail__dlm, ContactPointPhone__dlm        │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ Identity Resolution Ruleset Execution
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                      THE UNIFIED DMO SCHEMA                             │
│                                                                         │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │ UnifiedIndividual__dlm (1:1 Master Profile)                       │  │
│  │ - UnifiedRecordId__c (Primary Key / Cluster GUID)                 │  │
│  │ - Reconciled Attributes: FirstName, LastName, BirthDate, etc.     │  │
│  └──────────────────┬─────────────────────────────┬──────────────────┘  │
│                     │ 1:N                         │ 1:N                 │
│                     ▼                             ▼                     │
│  ┌─────────────────────────────────────┐  ┌──────────────────────────┐  │
│  │ UnifiedContactPointEmail__dlm       │  │ UnifiedLinkIndividual    │  │
│  │ - Multiple deduplicated emails      │  │ - SourceRecordId__c      │  │
│  │ - UnifiedRecordId__c (Foreign Key)  │  │ - UnifiedRecordId__c     │  │
│  └─────────────────────────────────────┘  └──────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────┘

The Core Unified Entities

1. UnifiedIndividual__dlm:

   • Cardinality: Exactly one record per identity cluster (1:1).
   • Primary Key: UnifiedRecordId__c (a globally unique, system-generated identifier representing the cluster).
   • Content: Contains the single surviving attribute value for each field mapped from the source Individual__dlm, as dictated by the configured reconciliation rules (e.g., single surviving FirstName, LastName, BillingCity).

2. Unified Contact Points (UnifiedContactPointEmail__dlm, UnifiedContactPointPhone__dlm, UnifiedContactPointAddress__dlm):

   • Cardinality: One-to-many (1:N) relative to UnifiedIndividual__dlm.
   • Crucial Architectural Concept: While UnifiedIndividual flattens profile attributes into a single row, Unified Contact Points are NOT flattened into a single value. A customer legitimately possesses multiple email addresses (personal, work, school) and multiple phone numbers.
   • Contact Point Deduplication: Within an identity cluster, Data Cloud deduplicates identical contact point values. If Source Record A and Source Record B both contain sarah.smith@example.com, only a single row for sarah.smith@example.com is written to UnifiedContactPointEmail__dlm. However, if Record A has sarah@work.com and Record B has sarah@personal.com, both distinct rows are preserved under the same UnifiedRecordId__c.

3. UnifiedLinkIndividual__dlm (and UnifiedLinkContactPoint bridge objects):

   • Cardinality: Many-to-one (N:1) mapping from source records to unified records.
   • Role: The indispensable lineage bridge table connecting source record identifiers to the unified identity cluster.

Comparison: Unified Individual vs. Unified Contact Points

---

The UnifiedLink Bridge Object: Architecture and Relational Traversal

The UnifiedLinkIndividual__dlm object is the architectural backbone of Data Cloud's Customer 360 data model. Without this bridge, downstream services would be unable to connect operational transactions (orders, website clicks, service cases) to unified customer profiles.

Schema Anatomy of UnifiedLinkIndividual__dlm

How Queries and Downstream Engines Traverse the Bridge

Operational data streams (such as e-commerce orders, loyalty transactions, or email clicks) are ingested and mapped to Engagement DMOs (e.g., SalesOrder__dlm). These engagement records link to the source Individual__dlm via foreign keys like IndividualId__c.

When a marketer builds a segment or a data engineer writes a Calculated Insight on UnifiedIndividual, Data Cloud automatically leverages UnifiedLinkIndividual__dlm to execute the necessary underlying joins behind the scenes:

/* Logical query path executed internally by Data Cloud */
SELECT 
    u.UnifiedRecordId__c,
    u.FirstName__c,
    u.LastName__c,
    SUM(o.OrderTotalAmount__c) AS UnifiedLifetimeSpend
FROM UnifiedIndividual__dlm u
JOIN UnifiedLinkIndividual__dlm link 
    ON u.UnifiedRecordId__c = link.UnifiedRecordId__c
JOIN Individual__dlm ind 
    ON link.SourceRecordId__c = ind.Id__c
JOIN SalesOrder__dlm o 
    ON ind.Id__c = o.SoldToCustomerId__c
GROUP BY u.UnifiedRecordId__c, u.FirstName__c, u.LastName__c

Activation Traversal

When activating a segment to an external activation target (e.g., Meta Ads, Google Customer Match, Amazon S3, or Salesforce Core CRM):

• The segment audience is evaluated at the UnifiedIndividual level.
• When the activation payload is compiled, the activation engine traverses UnifiedLinkIndividual__dlm to retrieve the original source CRM Contact IDs or Marketing Cloud Subscriber Keys required by the downstream destination.

---

Identity Resolution Lifecycle & Re-Clustering Dynamics

Identity Resolution in Data Cloud does not execute synchronously on record creation. Instead, it operates as an asynchronous batch calculation engine scheduled to run at regular intervals (typically once every 24 hours, or triggered manually via the UI/API).

Connected-Component Graph Modeling

Data Cloud represents customer identity as an undirected graph:

• Nodes: Source individual records and contact point records.
• Edges: Matches established between records by configured Match Rules.
• Clusters: The connected components of the graph. Any group of nodes connected directly or indirectly by edges constitutes a single Unified Individual profile.

SCENARIO A: STABLE SEPARATE CLUSTERS
Cluster 1: [CRM Contact A] ──(Phone Match)── [POS Customer B]  ==> Unified Profile 1
Cluster 2: [Web User C]     ──(Email Match)── [Marketing Sub D] ==> Unified Profile 2

SCENARIO B: CLUSTER MERGING (Inbound Record E arrives with CRM A's Phone and Web C's Email)
[CRM Contact A] ──────(Phone Match)────── [Record E]
       │                                       │ (Email Match)
[POS Customer B]                        [Web User C] ───(Email)─── [Marketing Sub D]

==> All 5 records now form ONE connected component: Unified Profile 1 & 2 MERGE into Unified Profile 3!

Profile Re-Clustering: Merging vs. Splitting

Because Identity Resolution recalculates the global connected components on each execution cycle, customer profiles are dynamic:

1. Cluster Merging (Transitive Linkage):
   • Occurs when a new or updated record introduces an edge connecting two previously disjoint clusters.
   • In the diagram above, Record E matches both Cluster 1 (via phone) and Cluster 2 (via email). On the next ruleset run, Cluster 1 and Cluster 2 collapse into a single unified profile.
2. Cluster Splitting:
   • Occurs when an existing record is deleted, or when an attribute (such as an email or phone number) is modified in a source system, severing the bridging edge.
   • If the severed edge was the sole path connecting two sub-graphs, the unified profile splits into two distinct Unified Individual profiles on the next ruleset run.

[!CAUTION] Dynamic Unified IDs Because clusters can merge and split over time, UnifiedRecordId__c values are system-generated and dynamic. If two clusters merge, one of the original UnifiedRecordIds will be retired and a master UnifiedRecordId will represent the merged cluster. Enterprise applications should never treat UnifiedRecordId as an immutable external identifier; external integrations should always rely on source system keys resolved through UnifiedLinkIndividual__dlm.

Diagnosing and Troubleshooting Identity Resolution Issues

When managing enterprise customer data, Identity Resolution rulesets can produce unexpected outcomes. A certified consultant must be proficient in inspecting ruleset run history, interpreting diagnostic metrics, identifying root causes, and implementing remediation protocols.

The Consolidation Rate Metric

The primary health metric for Identity Resolution is the Consolidation Rate. It quantifies the degree to which source records have been merged into unified profiles:

$\text{Consolidation Rate} = 1 - (\text{Total Unified Records} / \text{Total Source Records}) = (\text{Total Source Records} - \text{Total Unified Records}) / \text{Total Source Records}$

• Interpretation:
  • If 1,000,000 source records produce 750,000 unified profiles: Consolidation Rate = 1 - (750,000 / 1,000,000) = 25%.
  • In typical enterprise B2C environments with multi-channel touchpoints (CRM, E-Commerce, POS, Mobile), a healthy consolidation rate generally ranges between 10% and 35%.

Anomaly Detection: Metric Shift Signatures

---

The Over-Grouping Catastrophe: Root Causes & The Snowball Effect

Over-grouping (also known as runaway merging or catastrophic clustering) is the most dangerous failure mode in Identity Resolution. If 50,000 distinct consumers are merged into a single unified profile, sensitive transactional histories are commingled, segmentation criteria become corrupted, and privacy compliance (GDPR/CCPA) is compromised.

The Four Culprits of Over-Grouping

1. Placeholder & Dummy Email Addresses:
   • Cashiers or web users entering placeholder emails when a real email is optional or unknown: test@test.com, guest@store.com, noemail@domain.com, customer@retailer.com, admin@company.com.
   • Because Identity Resolution applies deterministic exact matching on normalized email, every customer who ever checked out with test@test.com is linked into the same cluster.
2. Default & Shared Phone Numbers:
   • In-store POS terminals where cashiers input the retail store's own phone number (555-1212) or generic dummy strings (999-999-9999, 123-456-7890, 000-000-0000) to bypass mandatory checkout prompts.
3. Household Sharing (Spousal / Family Aliases):
   • Spouses or family members sharing a single home landline or a joint email address (smithfamily@gmail.com). If a match rule links on email alone without validating first name, separate human beings are collapsed into one profile.
4. Overly Permissive Fuzzy Match Rules:
   • Configuring fuzzy matching on First Name and Last Name combined with broad geographic criteria (e.g., Matching on City and State without Street Address or Postal Code), causing common names (e.g., "John Smith in Chicago") to collapse hundreds of distinct individuals.

The Snowball Effect (Transitive Graph Poisoning)

Over-grouping rarely remains isolated to the dummy record itself. It cascades exponentially through the graph:

1. Customer 1 (Alice) enters test@example.com and Alice's real Mobile Phone (555-0001).
2. Customer 2 (Bob) enters test@example.com and Bob's real Home Phone (555-0002).
   ──► Alice and Bob MERGE into Cluster A via test@example.com.
3. Customer 3 (Charlie) shares a Home Phone with Bob (555-0002) and enters Charlie's real Email.
   ──► Charlie MERGES into Cluster A via Home Phone (555-0002).
4. Customer 4 (David) shares David's real Email with Charlie...
   ──► THE ENTIRE DATABASE MERGES TRANSITIVELY INTO A SINGLE SUPER-CLUSTER!

---

Enterprise Upstream Data Hygiene & Consultant Governance

The fundamental architectural principle for Data Cloud identity management is:

[!IMPORTANT] The Golden Rule of Identity Resolution Cleanse and nullify dummy data UPSTREAM during ingestion. Never attempt to fix dirty data using loose reconciliation rules or downstream segment filters. Once a dummy record creates a graph edge in Identity Resolution, the damage is already done.

1. Ingestion Formula Nullification: The Primary Defense

In Salesforce Data Cloud, the Identity Resolution matching engine strictly ignores NULL values. A null value in Record A will never match with a null value in Record B.

Consultants should implement Ingestion Formula Fields directly on incoming Data Streams to detect known dummy, placeholder, or invalid strings and convert them to NULL before they land in the Data Lake Object (DLO):

/* Ingestion Formula: Cleansing Email on Web Ingestion Data Stream */
IF(
    LOWER(TRIM(source.RawEmail__c)) IN (
        'test@test.com', 
        'test@example.com', 
        'none@none.com', 
        'guest@retailer.com', 
        'noemail@domain.com', 
        'admin@admin.com'
    ) 
    OR source.RawEmail__c LIKE '%@example.com' 
    OR NOT(source.RawEmail__c LIKE '%@%.%'),
    NULL,
    LOWER(TRIM(source.RawEmail__c))
)

/* Ingestion Formula: Cleansing Phone Numbers on POS Data Stream */
IF(
    SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(source.RawPhone__c, '(', ''), ')', ''), '-', ''), ' ', '') IN (
        '0000000000', 
        '9999999999', 
        '1234567890', 
        '5555555555'
    ),
    NULL,
    SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(source.RawPhone__c, '(', ''), ')', ''), '-', ''), ' ', '')
)

2. Compound Match Rule Architecture for Household Disambiguation

To prevent spouses or household members sharing contact points from accidentally merging, consultants must configure compound match rules rather than single-attribute rules:

• Weak Rule (Causes Over-Grouping): Exact Normalized Email alone.
• Robust Compound Rule: Exact Normalized Email AND Fuzzy First Name (High Precision).
• Phone Disambiguation Rule: Exact E.164 Phone AND Exact Normalized Last Name.

3. Pre-Production Governance & Testing Protocol

Before deploying rulesets to production, consultants must follow a structured validation methodology:

1. Sandbox / Data Space Testing: Test rulesets in an isolated non-production Data Space using a representative data sample.
2. Run History Inspection: Execute the ruleset and inspect the Consolidation Rate, Unified Record count, and Match Pair count.
3. Match Pair Outlier Analysis: If any single cluster contains an abnormal number of records (e.g., > 20 records in a B2C model), immediately inspect the contributing source records to identify the shared bridging attribute.
4. Audit Drift Monitoring: Establish ongoing governance by logging weekly consolidation rates to catch new dummy data patterns before they infect downstream activations.