Identity resolution in Salesforce Data 360 links records from multiple sources into unified profiles for individuals, accounts, leads, or households. It uses rulesets containing match rules and reconciliation rules. Match rules decide which source profiles belong together; reconciliation rules choose summary values for unified fields when several source records provide different values. The result is a unified profile view, not a master-data-management system that rewrites source records.
Salesforce renamed Data Cloud to Data 360 in October 2025, but the approved internal destination still uses the historical Data Cloud slug. The current Salesforce Certified Data 360 Consultant exam explicitly includes harmonization and unification, making identity resolution a core implementation skill.
Model the data before writing match rules
Identity resolution depends on correct DMO mappings and relationships. Individual or Account records need the appropriate contact points, party identifiers, or external identity links available for matching.
A poorly modeled email or phone field cannot be rescued by a clever match rule. Validate required mappings and source quality first.
Choose the correct unification type
Data 360 supports multiple unification patterns, including Individuals, Accounts, real-time profile matching, external links, and other specialized forms. The primary DMO selected for the ruleset determines which objects are unified and what unified outputs are created.
Select the type from the business entity you are trying to resolve. Mixing person-level and account-level identity concepts creates ambiguous profiles and unreliable downstream segmentation.
Build match rules from strong evidence
A match rule contains one or more criteria. Data 360 unifies profiles when all criteria inside one rule are satisfied, and multiple rules can provide different valid paths to a match.
Stricter criteria improve precision but may miss legitimate matches. Looser criteria increase consolidation but can merge different people. Use data profiling and labeled examples to balance false matches and missed matches.
Use normalized and fuzzy methods intentionally
Names, addresses, phones, and emails often need normalization or fuzzy comparison because source systems store them differently. Data 360 supports match methods that transform or compare values according to the field type.
Fuzzy matching should not become a substitute for strong identifiers. Party IDs, external identity links, or stable first-party identifiers can provide much higher-confidence matches when available.
Use reconciliation rules for unified values
After records match, reconciliation rules decide which source value represents a unified field that can hold only one summary value. The preferred source may differ by attribute: CRM could be authoritative for account status, while a verified identity system owns legal name.
Document source priority so users understand why the unified profile displays one value even when another source contains something different.
Source records and lineage remain important because identity resolution does not delete or overwrite source profiles. Unified objects reference the matched records while source data remains available. This is important because different business use cases may need different source values or contact points.
Lineage also supports investigation. If an incorrect unified value appears, operators need to trace it back to the source profiles and reconciliation logic that produced it.
Measure consolidation quality
Monitor match rates, unified-profile counts, unmatched populations, and representative false-positive or false-negative cases. A dramatic increase in consolidation after a rule change may be an improvement or a serious overmatch.
Review results with business owners who know the customer population. Identity quality cannot be judged only from one aggregate percentage.
Use unified profiles carefully in activation
When activating person-level audiences that rely on identity resolution, Salesforce recommends Unified Individual as the activation membership. This avoids sending multiple source records for one resolved person.
Contact-point selection still needs policy. Choose the appropriate email, phone, or channel based on source priority, engagement, consent, and the destination’s requirements.
Protect identity data
Identity resolution combines data across systems, which can increase sensitivity even when each individual source is ordinary CRM data. Limit access to unified profiles and match results according to business purpose.
The approved privacy and security context is relevant because the ability to link identities can create privacy risk if used outside the original purpose or exposed too broadly.
Feed trusted identity into downstream experiences
Unified profiles can support segmentation, activation, calculated insights, service workflows, personalization, and Agentforce grounding. That makes identity resolution upstream infrastructure for many visible customer experiences.
The Agentforce Specialist relationship is therefore meaningful: an agent that relies on customer context benefits from a trustworthy identity layer. The Salesforce platform is strongest when matching, reconciliation, governance, and downstream use are designed together rather than treating identity resolution as a one-time deduplication job.
Match-rule design should begin with labeled examples of true matches and true non-matches from the real customer population. Default rules are useful starting points, but names, addresses, and identifiers vary by country, product, and source. Validate precision and consolidation with data rather than assuming one default configuration fits every organization.
Multiple match rules provide alternative paths to unification. One rule may match normalized email plus name, another party identifier, and another fuzzy name plus address. Because satisfying any one rule can unify profiles, every rule must be safe independently. A permissive fallback rule can undermine several strict rules.
Match methods change how values are compared after normalization. Exact normalized email is different from fuzzy name or normalized phone. Use stronger identifiers where available and reserve fuzzy logic for attributes whose real-world variation requires it.
False positives can be more damaging than false negatives in some domains. Merging two different customers can expose one person’s data to another workflow, while failing to merge duplicates may only reduce personalization. Set match strictness according to the business risk rather than maximizing consolidation rate.
Reconciliation is not source correction. The unified profile can select one preferred name, address, or other field while source records remain unchanged. If a source system is wrong, fix it at the source as a separate data-quality process instead of assuming reconciliation repairs the operational system.
Source priority can vary by field. CRM may own service status, a commerce system may own recent purchase date, and an identity provider may own a verified email. Design reconciliation at the object and field level according to authority, recency, or another documented rule.
Identity-resolution rulesets should have version and change history. A small match-rule edit can merge or split many unified profiles on the next run. Review expected consolidation impact before activation and retain prior configuration for rollback or comparison.
Processing results and history provide useful operational signals. Track source profile counts, unified counts, consolidation rate, and run status over time. Sudden changes after source ingestion or rule changes deserve investigation even when the job itself completed successfully.
Real-time unification supports experiences that need a profile match within milliseconds, but its use should be justified by interaction latency. Scheduled rulesets may be simpler for analytics and campaign use cases where daily or periodic resolution is sufficient.
External identity links and party identifiers can incorporate matches established outside Data 360. These can be powerful when an enterprise master-data system already knows two profiles belong together. Govern the external identifiers carefully because they can force high-confidence linkage across sources.
Household unification is distinct from individual matching. Individuals can belong to households based on rules such as name and address or party identifiers, and one person can potentially relate to multiple household contexts. Do not treat household IDs as substitutes for individual identity.
Downstream consumers need to understand whether they use source Individual or Unified Individual. Segmentation and activation designed for one may behave differently with the other, particularly in member counts and contact-point selection.
Privacy review should consider inference risk. Combining records across systems can reveal a more complete picture of a customer than any source alone. Access to unified profiles should reflect the sensitivity of the combined result, not only the classification of each input field.
Testing should include near-duplicate names, shared household contact points, recycled phone numbers, shared business emails, changed addresses, and intentionally separate identities with similar data. These cases expose overmatching and undermatching that clean examples miss.
Identity resolution is successful when downstream teams can trust both the match and the explanation. The system should show which source records were linked, which rules enabled the match, how unified values were selected, and how rule changes affected consolidation. That transparency turns unification into governed customer-data infrastructure rather than opaque deduplication.
Match-rule tuning should use a confusion matrix or equivalent labeled review where the business risk justifies it. Count true matches, false matches, missed matches, and correct non-matches. Consolidation rate alone cannot show whether the rules are accurate.
Source-specific data quality can influence rule design. One system may have highly verified email addresses while another contains shared household emails. Use source or field characteristics when determining which attributes deserve stronger matching weight or source priority.
Normalized phone numbers and emails can still be recycled over time. A phone number reassigned to a new person can create a false historical link if the rules assume lifetime ownership. Consider temporal and source context for identifiers that are not permanently unique.
Shared family contact information is another common edge case. Spouses or household members can share addresses, emails, or phones, so person-level match rules should not rely on a weak combination that collapses several valid individuals into one unified profile.
Rule changes should be tested against known VIP, regulated, and high-value records because false unification can have larger consequences for those populations. A small manual review set can complement large statistical evaluation.
Reconciliation rules may need different strategies such as source priority, most frequent, or most recent values depending on the attribute. “Most recent” is only trustworthy if source timestamps are comparable and reflect the real business event.
Unified-profile IDs should not be treated as immutable source-system master keys unless Salesforce explicitly guarantees that behavior for the use case. Downstream integrations should rely on supported Data 360 identity semantics and be prepared for profile changes after rule updates.
Identity-processing cadence affects downstream freshness. Scheduled rulesets may update once per day or according to platform behavior, while real-time unification can serve interactive personalization. Align downstream SLAs with the actual matching mode.
When identity resolution feeds Agentforce, test that the agent does not expose cross-profile information after a rule change. An overmatch can become a conversational privacy incident if the agent retrieves data from the wrong unified customer.
Identity governance should include ruleset ownership, change approval, processing history, and escalation for suspicious consolidation shifts. The more downstream features depend on unified profiles, the more carefully the rules become part of shared infrastructure.
Ruleset documentation should include known limitations and examples of records intentionally left unmatched. A lower consolidation rate can be correct when the available evidence is too weak to justify merging profiles.
Keep match quality under review as source systems and customer behavior change over time.
Review continuously.
Keep it visible.
Keep it governed.
Review it.