Identity resolution is where a customer-data platform stops being a collection of imported records and starts becoming a system that can reason about people or accounts across sources. The hard part is not combining every record that looks similar. The hard part is combining records that represent the same real-world entity without collapsing different people into one profile or leaving obvious duplicates unresolved.
For the Salesforce Data 360 Consultant, identity resolution should be understood as a controlled sequence: ingest and map source data, define rulesets, match source records, reconcile competing attribute values, create unified profiles, and then monitor whether the resulting consolidation is accurate enough for segmentation, service, analytics, and activation.
Start with mapped source data, not with a matching rule
Identity resolution is downstream of data ingestion and data modeling. If email addresses are mapped inconsistently, phone numbers arrive in incompatible formats, postal addresses are incomplete, or identifiers have different meanings in different source systems, even a carefully designed ruleset will produce unstable results. Matching logic cannot repair a semantic mapping problem.
A practical design exercise starts by listing the sources that contribute person or account data and identifying which attributes are trustworthy in each one. CRM may be authoritative for a legal account name, commerce may have the freshest shipping address, a loyalty platform may own a membership identifier, and a marketing system may contain channel-specific contact points. The goal is to understand both the values and the provenance of those values before deciding how they should be matched.
Normalization matters because values that are semantically the same can be formatted differently. Phone numbers may contain country codes, punctuation, or extensions. Addresses may use abbreviations. Email addresses may differ only in case. Salesforce supports matching methods designed for exact, normalized, and fuzzy comparisons, but the organization still has to decide which attributes are strong enough to establish identity.
Match rules answer “which source records belong together?”
Match rules define the evidence required to link source profiles. A conservative rule might require an exact normalized email address plus an exact last name. A broader rule might allow fuzzy first-name matching together with a normalized phone number. Multiple match rules can coexist in a ruleset so that different combinations of evidence can produce a match.
The important design question is not whether an attribute can match; it is whether the match is sufficiently discriminating for the business risk. Household phone numbers, shared corporate email addresses, common surnames, recycled mobile numbers, and generic inboxes can all create false positives. A rule that works for consumer retail may be too aggressive for financial services or healthcare, where incorrectly merging two individuals can expose sensitive information.
Match logic should therefore be tested against known examples of both true matches and near-misses. If two records share an address and surname but represent different family members, the ruleset should not merge them merely because those fields agree. If the same person appears as “Liz,” “Elizabeth,” and “Eliza” with the same normalized email, a controlled fuzzy-name rule may correctly connect the records.
Reconciliation rules answer a different question
Matching determines which source records are linked. Reconciliation determines which value should represent a unified attribute when the linked records disagree. These are separate decisions. Two records can clearly belong to the same person while still containing different first names, addresses, loyalty statuses, or phone numbers.
Data 360 supports approaches such as recency, frequency, and source priority. Recency can be appropriate when the most recently updated value is usually the best reflection of the customer. Frequency can help when repeated agreement across several sources is meaningful. Source priority is useful when one system is intentionally authoritative, such as a mastered CRM record or a regulated system of record.
Source priority should be explicit rather than assumed. If the commerce platform is trusted for shipping address but CRM is trusted for account owner, the reconciliation policy should reflect that difference at the relevant field level. A single global rule such as “CRM always wins” is easy to understand but often too crude for real enterprise data.
A unified profile is linked and reconciled, not a destructive overwrite
A common misconception is that identity resolution creates one permanent “golden record” and discards the source records. The more accurate mental model is a unified profile linked to underlying source data. The unified view exposes reconciled attributes while retaining relationships back to the contributing records, allowing lineage and source context to remain available.
This matters operationally. If a service agent sees a reconciled phone number, analysts may still need to know which source supplied it. If a source system later corrects a record, the unified profile can change after identity resolution processes the new state. Unified profiles are therefore mutable: they can gain or lose linked records as source data changes or matching logic is revised.
That mutability is a feature, but it requires governance. Downstream teams should not treat a unified identifier as if every relationship beneath it can never change. Segments, calculated insights, analytics, and activations should be designed with the expectation that identity resolution is continuously refining the customer view.
Choose consolidation risk deliberately
Every identity-resolution design balances two error types. Under-matching leaves one person represented by multiple unified profiles. Over-matching joins different people into a single profile. Increasing the number or looseness of match rules can improve consolidation while also increasing false-positive risk.
The acceptable balance depends on the use case. A marketing audience may tolerate some under-matching because the cost is duplicate outreach. A service workflow that displays sensitive case history may require much more conservative identity evidence because an over-match can reveal another person’s information. High-risk activations should not inherit a permissive ruleset simply because it produces an attractive consolidation percentage.
Measure quality with reviewed examples, not only with a single aggregate rate. A higher consolidation rate can be good when it resolves genuine duplicates, but it can also hide aggressive matching. Sampling matched and unmatched populations, reviewing outliers, and comparing rulesets against known truth sets provide more meaningful evidence.
Use rulesets as testable configuration
Rulesets should be treated like governed logic, not one-time setup. Document the match rules, the business rationale for each attribute, reconciliation choices, expected false-positive and false-negative risks, and the data owners who approved them. When a rule changes, record why the change was made and which downstream use cases may be affected.
Salesforce supports comparing ruleset behavior, which makes controlled experimentation possible. One ruleset can remain conservative while a second tests an additional fuzzy or normalized rule. Compare consolidation behavior, inspect sample unified profiles, and decide whether the extra matches are genuinely correct before moving the change into production use.
Processing history and operational monitoring are equally important. A ruleset that worked well when three sources were connected can behave differently after a fourth source with weaker data quality is added. Identity resolution must be re-evaluated when data sources, mappings, business identifiers, or privacy requirements change.
Diagnose common failure modes by layer
When identity resolution produces surprising output, first decide whether the problem is mapping, matching, or reconciliation. If a phone number is never considered because it was mapped to the wrong data-model attribute, changing the match rule will not fix the issue. If the correct records are linked but the wrong email appears as the preferred value, the reconciliation logic is the likely problem.
Over-matching often comes from weak evidence: a fuzzy name combined with a household attribute, a shared identifier, or an overly broad normalization rule. Under-matching often comes from inconsistent formatting, missing fields, strict exact matching, or an attribute that is not populated across sources. Reconciliation errors commonly appear when source priority is not aligned with actual data ownership.
Another failure mode is assuming the identity layer is responsible for every duplicate. Some duplicates should be corrected upstream because they represent poor source-system controls rather than legitimate multi-source identities. Identity resolution can link records, but it should not become an excuse to leave preventable data-quality defects untreated.
Protect downstream use cases from identity mistakes
Identity decisions can propagate into segmentation, personalization, service, analytics, and activation. Before a unified attribute drives an important action, ask what happens if the profile is wrong. Marketing suppression, entitlement decisions, sensitive service context, and automated outreach can have very different risk profiles.
For higher-impact use cases, add safeguards such as stronger matching evidence, source restrictions, data-quality checks, activation filters, or human review. Keep privacy and consent context attached to the correct identifiers rather than assuming a profile merge automatically authorizes every downstream use of every linked attribute.
The wider Salesforce architecture also matters. Identity resolution is one part of a data lifecycle that includes ingestion, mapping, transformation, segmentation, activation, security, and governance. A trustworthy unified profile depends on all of those layers working together.
Design identity resolution for explainability
A strong implementation can answer four questions for any important unified profile: which source records were linked, which rule caused the match, why a particular reconciled value won, and how a reviewer can trace that value back to its source. If the team cannot explain those decisions, it will struggle to investigate privacy issues, data-quality complaints, and unexpected activations.
The best rules are not necessarily the most complex. They are the ones that use reliable evidence, make the tradeoff between under-matching and over-matching explicit, and remain understandable to the people responsible for customer data. Identity resolution succeeds when it creates a useful unified view without erasing provenance, overstating certainty, or turning similarity into identity without sufficient proof.