9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated

Reconciliation Rules: Most Frequent, Source Priority & Last Updated

In Salesforce Data Cloud, the creation of a unified Customer 360 profile is executed through a two-stage Identity Resolution engine. First, Match Rules analyze disparate customer records across enterprise touchpoints, identify deterministic and probabilistic linkages, and cluster related records into an identity graph. Second, once a cluster of source records is established, the platform must construct a single, authoritative master record—the Unified Individual (UnifiedIndividual__dlm).

Because contributing source records frequently contain contradictory or divergent data—such as different spellings of a name, conflicting postal addresses, or competing mobile numbers—Data Cloud requires deterministic logic to decide which attribute value survives on the unified profile. This decision engine is governed by Reconciliation Rules (also known as survivorship rules).

The Dual Engines: Match Rules vs. Reconciliation Rules

A frequent source of confusion on the Salesforce Certified Data Cloud Consultant exam is conflating Match Rules with Reconciliation Rules. While they operate within the same Identity Resolution ruleset, their architectural responsibilities are completely separate and decoupled.

┌─────────────────────────────────────────────────────────────────────────┐
│                     STAGE 1: MATCH RULES ENGINE                         │
│  Evaluates incoming source records and forms identity clusters.         │
│  Determines: "Do Record A (CRM), Record B (POS), and Record C (Web)     │
│  belong to the same living individual?"                                 │
│  Output: Identity Cluster Graph / Consolidation Rate                    │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │ Forms Cluster: [A + B + C]
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                 STAGE 2: RECONCILIATION RULES ENGINE                    │
│  Evaluates attribute values within each established cluster.            │
│  Determines: "Now that Records A, B, and C are clustered together,      │
│  which First Name, Mobile Phone, and Home Store should win?"            │
│  Output: Unified Individual Profile (Reconciled Field Values)           │
└─────────────────────────────────────────────────────────────────────────┘

Architectural Comparison Matrix

[!IMPORTANT] The Cardinal Exam Rule Changing a Reconciliation Rule NEVER alters the number of unified records in Data Cloud, and it NEVER changes the consolidation rate. If an exam question asks how to increase the consolidation rate or link more customer profiles together, modifying reconciliation rules is always an incorrect distractor. Only Match Rules control profile consolidation.

The Three Standard Reconciliation Methods

Data Cloud provides three standard reconciliation methods for resolving field conflicts on the Unified Individual object. Each method is tailored to specific business requirements, data volatility profiles, and organizational systems of record.

1. Last Updated (Recency / Most Recent)

• Operational Mechanics: Inspects the timestamp associated with each contributing source record within the cluster. The record possessing the most recent timestamp contributes its attribute value to the Unified Individual.
• Timestamp Evaluation: Data Cloud evaluates the date/time field mapped during data ingestion (typically the source system's LastModifiedDate or an explicit business timestamp mapped to the DLO). If no custom date field is mapped, the ingestion system timestamp (CreatedDate__c or LastModifiedDate__c) is utilized.
• Default System Status: Last Updated is the default reconciliation rule in Data Cloud. If an administrator maps a field to the Unified Individual and does not explicitly configure a custom reconciliation rule, Data Cloud automatically applies Last Updated.
• Ideal Business Use Cases:
  • Highly volatile contact information that changes frequently over time (e.g., Mobile Phone Number, Mailing Address, Opt-In Consent Status).
  • Behavioral or situational attributes where current state supersedes historical records (e.g., Current Employer, Job Title, Preferred Channel).
• Limitations: Susceptible to data corruption from batch ETL bulk-updates. For example, if a legacy database runs an automated script touching all records, their LastModifiedDate may be updated today, causing outdated legacy values to overwrite newer, accurate data.

2. Source Priority (Hierarchical System-of-Record)

• Operational Mechanics: Allows the consultant to establish an explicit, ordered ranking of data sources. When reconciling an attribute, Data Cloud evaluates the contributing records against this priority hierarchy and selects the value from the highest-ranked source.
• Hierarchy Configuration: Configured in the Identity Resolution UI by ordering the data streams or source objects associated with the Individual DMO (e.g., Tier 1: Service Cloud Contact; Tier 2: Sales Cloud Lead; Tier 3: B2C Commerce Account; Tier 4: Marketing Cloud Subscriber).
• Handling of Null / Blank Values (Crucial Fallback Behavior):
  • If the highest-priority source record contains a NULL or empty string for the attribute, Data Cloud does NOT overwrite populated data with null.
  • Instead, the reconciliation engine automatically traverses down the hierarchy to the next highest-priority source that contains a non-null, populated value.
  • Valid data from a lower-priority source is always preserved over a blank from a higher-priority source.
• Tie-Breaker Mechanics:
  • What occurs if a cluster contains multiple records originating from the same priority source tier (e.g., two distinct Service Cloud Contact records clustered together)?
  • The Tie-Breaker is Last Updated: When multiple records share the highest available priority rank, Data Cloud selects the value from the record with the most recent LastModifiedDate among that tied tier.
• Ideal Business Use Cases:
  • Verified, authoritative legal identifiers where human validation occurred (e.g., Legal First Name, Legal Last Name, Social Security Number / Tax ID, Date of Birth from a core CRM or KYC platform).
  • Enterprise master data management (MDM) integrations where a single system is legally designated as the system of record.

3. Most Frequent (Statistical Mode / Consensus)

• Operational Mechanics: Evaluates all contributing source records in the cluster and counts the frequency of each unique attribute value. The value that appears with the highest occurrence count (the statistical mode) wins and populates the unified field.
• Consensus-Driven Logic: Treats data sources as voting members. Even if a low-priority system contains an erroneous value, consensus among other systems overrides it.
• Tie-Breaker Mechanics:
  • What occurs if two or more distinct values have identical frequency counts (e.g., Store #101 appears twice and Store #205 appears twice in a four-record cluster)?
  • The Tie-Breaker is Last Updated: When a frequency tie occurs, Data Cloud evaluates the tied candidates and selects the value from the record with the most recent LastModifiedDate.
• Ideal Business Use Cases:
  • Categorical attributes, preferences, and demographic values that are captured across multiple touchpoints but rarely change (e.g., Preferred Retail Store, Preferred Language, Gender, Country of Residence, T-Shirt / Apparel Size).
• Limitations: In small clusters containing only two records with differing values (a 1-to-1 split), Most Frequent immediately defaults to Last Updated, rendering the frequency calculation moot.

Comprehensive Reconciliation Methods Comparison

Field-Level Reconciliation Customization

In Salesforce Data Cloud, reconciliation rules are not applied uniformly across an entire object. Instead, rules are configured field-by-field on the UnifiedIndividual__dlm object. This granular flexibility enables enterprise architects to align each specific customer attribute with its natural business lifecycle.

┌─────────────────────────────────────────────────────────────────────────┐
│                     UNIFIED INDIVIDUAL FIELD MAPPING                    │
├───────────────────┬─────────────────────────┬───────────────────────────┤
│ Field Name        │ Reconciliation Rule     │ Architectural Rationale   │
├───────────────────┼─────────────────────────┼───────────────────────────┤
│ FirstName         │ Source Priority         │ CRM Contact > Web Lead    │
│ LastName          │ Source Priority         │ Core CRM is Master        │
│ BirthDate         │ Source Priority         │ KYC Verified Source       │
│ MobilePhone       │ Last Updated            │ Captures recent changes   │
│ MailingAddress    │ Last Updated            │ Captures recent moves     │
│ PreferredStore    │ Most Frequent           │ Long-term shopping habit  │
│ PreferredLanguage │ Most Frequent           │ Consensus across apps     │
│ OptInStatus       │ Last Updated            │ Compliance recency        │
└───────────────────┴─────────────────────────┴───────────────────────────┘

Enterprise Design Scenario: The Multi-Source Dilemma

Consider a global retailer operating three primary systems:

1. Service Cloud: Contact records maintained by call center agents during customer service interactions.
2. B2C Commerce: E-Commerce customer profiles created during online checkouts.
3. Marketing Cloud: Subscriber profiles populated via newsletter signup forms.

If the customer's identity cluster contains records from all three systems, applying a single global rule would compromise data integrity:

• Applying Last Updated globally: A customer enters a typo in a web newsletter form yesterday (Fname: Jhn), which immediately overwrites their verified legal name in Service Cloud (Jonathan).
• Applying Source Priority globally (Service Cloud > Commerce > Marketing): An old phone number entered in Service Cloud five years ago permanently supersedes a new, verified mobile number entered during an online checkout yesterday.

The Solution: Field-level customization. The architect assigns Source Priority to FirstName and LastName (Service Cloud > Commerce > Marketing) to protect legal identity integrity, while assigning Last Updated to MobilePhone and MailingAddress to capture fresh contact data.

Default Behavior and System Fallbacks

When deploying and maintaining Identity Resolution rulesets, consultants must understand how the engine behaves when configuration options are omitted or edge cases occur:

Unconfigured Attributes

When a standard or custom field on the Individual DMO is mapped to the UnifiedIndividual DMO, Data Cloud automatically assigns Last Updated as the default reconciliation rule. If the consultant does not navigate to the reconciliation canvas to customize the field, Last Updated will govern survivorship in production.

All-Null Attributes

If all contributing source records in an identity cluster contain a NULL or blank value for a specific attribute, the resulting field on UnifiedIndividual__dlm will be NULL. Data Cloud never synthesizes placeholder data.

Single-Record Clusters

For source records that do not match any other records (un-clustered individuals), the Unified Individual record directly mirrors the single source record's attributes. Reconciliation rules are only actively computed when two or more source records participate in the cluster.

Critical Exam Traps & Consultant Pitfalls

[!WARNING] Exam Trap 1: The "Consolidation Rate" Distractor Scenario: "The marketing team wants to increase the Identity Resolution consolidation rate from 20% to 35%. Which configuration change should the consultant make?"

• Distractor: "Change the reconciliation rule on First Name and Last Name from Last Updated to Most Frequent."
• Why it's wrong: Reconciliation rules NEVER alter consolidation rates or cluster membership. To increase consolidation, the consultant must modify Match Rules (e.g., adding fuzzy match criteria, incorporating Party Identification matching, or matching on normalized phone numbers).

[!CAUTION] Exam Trap 2: The "Null Overwrite" Myth Scenario: "Source Priority is configured as Service Cloud (1) > POS (2). A Service Cloud record has a blank Email field, while a POS record has 'sarah@example.com'. Which value survives?"

• Distractor: "NULL survives because Service Cloud is the top priority source and its null value overrides lower sources."
• Why it's wrong: Source Priority skips nulls. Data Cloud will traverse to POS and populate 'sarah@example.com'.

[!NOTE] Exam Trap 3: The Universal Tie-Breaker Every tie-breaker scenario in Data Cloud Identity Resolution is resolved by Last Updated. Whether two records share the same source priority tier or two values share the identical occurrence count in Most Frequent, the record with the most recent timestamp wins.