Data 360's Identity Resolution Default Is Wrong for Patient Records
Salesforce renamed Data Cloud to Data 360 in October 2025, bundling it into the Agentforce 360 rebrand alongside new features like Tableau Semantics and Intelligent Context. None of that changes what identity resolution is underneath: match rules and reconciliation rules working against whatever fields an admin mapped. What should change, for any healthcare organization adopting it, is how identity resolution gets configured. The matching logic that ships as a reasonable default for a retail customer profile is the wrong default for a patient record, and most implementations never revisit it.
What identity resolution actually decides
Data 360 unifies records from multiple source systems into a single profile using two mechanisms: match rules, which decide whether two records represent the same person, and reconciliation rules, which decide which value wins once records are linked. A guide to the feature lays out the common failure modes plainly: match rules that lean on one field, like email alone, under-match wherever that field is not reliably captured, and teams frequently ship with default matching rules rather than a deliberately designed ruleset. Neither failure mode is exotic. Both are what happens when identity resolution is treated as a configuration checkbox instead of an architecture decision.
The same source names the asymmetry that matters most for regulated data: a false match is usually more costly than a missed match, and rulesets should be designed with that asymmetry in mind. For insurance and banking, that is a compliance and fraud problem. For healthcare, it is a different kind of problem, because the record on the other side of the match is a person’s clinical history.
Why a false merge in healthcare is not a data quality bug
Consolidating two patients into one profile is the mirror image of splitting one patient into duplicate profiles. Duplicates are an annoyance: care teams see a fragmented history, marketing sends two emails instead of one, reporting double-counts a handful of people. A false merge is worse in kind, not just degree. It attaches one patient’s allergies, medications, and diagnoses to another patient’s identity. A workflow built on that unified profile now surfaces someone else’s clinical picture as fact, and every downstream system that trusts the profile inherits the error silently.
This is why identity resolution for patient data cannot be tuned to the general-purpose defaults Data 360 ships with. A comparison of Health Cloud and Data Cloud frames the decision correctly: Data 360 becomes necessary once an organization has multiple primary data systems, or duplicate and conflicting records that reliable identity matching would resolve, and identity resolution applies matching rules to reconcile patient identifiers that do not line up cleanly across those systems. What that framing leaves unsaid is that the matching threshold appropriate for reconciling a marketing contact and a support ticket is not the threshold appropriate for reconciling a patient chart. The tool is the same. The tolerance for error is not.
The mapping step where this actually gets decided
Identity resolution in Data 360 depends on mandatory data mappings before any matching happens at all. Salesforce’s own documentation is specific about this: every Data Model Object needs a primary key mapped from the source system, or the mapping definition will not save at all. The identity fields that feed matching beyond that, individual ID, name, contact point email, contact point phone in E.164 format, contact point address, and party identification, are documented as required too, and Salesforce’s own guidance is that if any of them is missing, identity resolution may not function properly and features like deduplication and segmentation degrade in performance.
A ruleset that technically saves and technically runs but degrades quietly is, in our judgment, the more dangerous failure mode for a patient population, worse than one that fails loudly enough to get fixed. For a patient population, the party identification mapping is where most of the real work sits. Medical record numbers, insurance member IDs, and any cross-system patient identifier should be mapped as party identifiers, not folded into a generic ID field, because that is what lets a match rule use an exact, authoritative identifier instead of falling back to fuzzy name-and-address matching. Skip that step and identity resolution does not fail loudly. It falls back to weaker signals and produces plausible-looking merges that are wrong.
What we would do
We treat identity resolution rulesets for clinical data as a reviewed architecture artifact, not a Data 360 setup task, the same discipline we apply to the platform behind Ariv Health. Concretely: map every authoritative patient identifier, medical record number, insurance member ID, to party identification rather than relying on name and contact fields to carry matching on their own. Require at least two independent signals to agree before an automatic merge fires, so a fuzzy name match alone never consolidates two records. Route anything that clears the threshold on a single weak signal to a human review queue instead of an automatic merge. And monitor the consolidation rate after every ruleset change, the same signal the identity resolution guide above recommends, because a sudden jump in merges is the first sign a rule is matching more aggressively than intended, and in healthcare that sign needs to trigger a rollback, not a shrug.
None of this is difficult to build. It is easy to skip, because the default configuration works fine in a demo and the failure mode only shows up once real patient volume runs through it. The rename to Data 360 changed how Salesforce talks about the product. It did not change the fact that identity resolution, for a patient population, is a clinical safety control wearing a data engineering interface, and it deserves the review that framing implies.