We are at Dreamforce 2026, Industry Pavilion at San Francisco
June 4, 2025
Identity resolution decides which source records describe the same person, then merges them into one profile. In Salesforce Data Cloud, that work runs through a ruleset with two halves: match rules that decide which records belong together, and reconciliation rules that decide which value wins on the merged result. Both halves are configurable, and both fail in opposite directions.
Here is how that failure shows up. A retailer unifies web, loyalty, and support data. The match rule includes a fuzzy name comparison and a normalized city field, because that lifted the match rate in testing. Two months later a service agent opens a case and sees order history belonging to a different customer with the same common name in the same city. Nobody typed anything wrong. The rule was too loose, and nobody validated the merged profiles first.
This post covers what actually decides whether identity resolution works. What each half of the ruleset does. Which of the three match methods to use and where each breaks. Why an over-match is worse than a duplicate. And what re-running a ruleset costs you.
Identity resolution is not a setting you switch on. It is a ruleset you configure, run, and then validate.
A ruleset targets a data model object, usually the Individual DMO, and produces unified profiles from your mapped source records. Every unified profile keeps links back to the sources that formed it, so you can trace any merged value to where it came from.
Table 1 — The Two Halves of an Identity Resolution Ruleset
A match rule is a set of attributes that must agree before two records are treated as one person. You can define several rules in one ruleset, and a record pair matches if it satisfies any of them. That matters: adding a rule can only widen matching, never narrow it.
Reconciliation then picks one value per field to produce the golden record. Source priority trusts a named system first. Most recent trusts the latest update. Set these per field rather than accepting defaults — email usually wants source priority, since a verified CRM record beats a web form, while a mailing address usually wants most recent, because people move. Write each decision down. Six months later nobody remembers why the loyalty platform outranks the CRM.
One exception: keep consent flags out of the reconciliation contest. If one record opted out and another opted in, neither source priority nor recency is a defensible basis for a permission decision. Enforce the most restrictive state at segmentation and activation instead, and test it by merging two conflicting records in a sandbox.
Salesforce has renamed the product. Its own page reads "Data 360 (Formerly Data Cloud)" and states Data 360 is the official new name.
Nothing about identity resolution changed. But carry both terms in your documentation, because contracts and tenders will say Data Cloud for years. Note also that Data 360 is not Customer 360 — vendor decks blur the two constantly. Our guide on extracting data from Data 360 covers the change in more depth.
Each attribute in a match rule gets a method. There are three, and they are not interchangeable.
Table 2 — Match Methods Compared
Three practical points follow.
Salesforce documents real-time matching as limited to exact and exact normalized methods. If you need a real-time unified profile, fuzzy is off the table. Confirm the current limit against Salesforce's documentation, since these constraints move between releases.
Do not mix fuzzy and exact methods carelessly in one rule. That combination can behave in ways teams do not expect, and duplicates that should be caught slip through.
Fuzzy on a name field plus a broad geographic field is the classic over-match recipe. Two unrelated people named James Miller in Dallas will merge. Configuration walkthroughs are posted regularly on Apex Hours if your team is learning the interface.
Most identity resolution problems are sequencing problems. The ruleset was configured before the foundation was ready. Three things come first, in this order.
Model and map before you match. Identity resolution can only compare attributes mapped into your data model. An unmapped field is invisible to every rule you write. A rule referencing a mostly-empty field produces what looks like a rule failure and is actually a mapping gap.
Audit your primary keys. Every source record needs a unique key within its data stream, because duplicate keys get discarded on ingestion. There is also a behavior that catches teams out: records sharing the same Individual ID unify automatically, with no ruleset involved. If two systems reuse an identifier for different people, they merge before your rules ever run. Our Salesforce Data 360 practice treats the ruleset as versioned configuration, because it behaves like production code.
Measure contact point coverage. Match quality tracks coverage almost linearly. If forty percent of records carry no email and no phone, no rule design recovers them. Set your match-rate target against what your data supports, not against a number from a demo. Data model design patterns are covered well by Salesforce Codex.
Under-matching and over-matching are not two versions of the same mistake. They have different severities and different owners.
Under-matching leaves duplicates. The same person gets two emails, your customer count inflates, and an agent sees part of the history. That is a reporting and experience cost. It is recoverable, and you fix it by widening rules.
Over-matching merges two different people. Now person A's order history, cases, and contact details appear wherever person B's profile is surfaced — the agent console, a marketing email, a portal, an AI agent's grounding data. That is not a data quality defect. That is one customer seeing another customer's information, and in a regulated industry it is a reportable event. It is also harder to unwind, because the merged profile has already been consumed downstream. Match-rule design threads appear regularly on Forcetalks.
Because the two failures are asymmetric, tune asymmetrically. Start with the strictest rules that work — exact and exact normalized on stable identifiers only. Then widen one rule at a time, and after each change read twenty newly merged profiles by hand. Twenty profiles reviewed by a person tells you more than a match-rate percentage. Stop when the review produces merges you cannot defend. That point is your ceiling, and it is usually lower than the business case assumed.
Both modes exist, and the choice is architecture rather than preference.
Scheduled resolution runs the ruleset on a cadence. It supports every match method, including fuzzy, and suits batch enrichment, legacy cleanup, and analytics.
Real-time resolution resolves identity as data arrives. It suits live personalization, an agent handling an inbound call, and AI agents grounding on a profile. Its constraint is the method limit above.
Most orgs need both, and the mistake is treating that as one decision. Decide per use case which freshness the business actually requires. A quarterly campaign does not need sub-second resolution, and paying for it is cost with no return. Our Salesforce implementation services team maps each use case to a mode during design rather than after go-live.
No competing guide mentions this, and it surprises teams in month three.
Data Cloud is consumption-priced, and identity resolution is a metered operation. Running a ruleset against a large profile set consumes credits. Re-running it after every tweak consumes them again. A team iterating on match rules in production can burn consumption nobody budgeted, because sandbox volumes were too small to notice.
Check your own consumption dashboards for the real figures. There is no universal number, and anyone quoting you one has not looked at your data volume.
The second cost is blast radius. Changing a match rule re-computes unified profiles. Profile IDs shift. Segments change membership. Activations push different audiences. AI agents ground on different data.
So rule changes belong in a release process, not a Tuesday afternoon. Treat the ruleset as a deployable artifact: change it in a sandbox, validate the merged output, then promote it with downstream dependencies identified. Deployment patterns for this are documented in depth by Jitendra Zaa.
Run these before any team, dashboard, or agent treats unified profiles as true.
Identifier uniqueness audited. No identifier reused for different people across sources, so nothing unifies silently.
Merged profiles reviewed by hand. At least twenty new merges read and defensible, not just a match rate.
Over-match cases tested deliberately. Near-duplicate test records for common names in dense cities stay separate.
Consent tested through a merge. Two conflicting records merged in a sandbox, and activation still excludes the profile.
Downstream dependencies listed. Every segment, activation, and agent built on these profiles inventoried before a rule changes.
Each takes under an hour. A check that fails now costs a fix. The same check failing after your service team trusts the data costs a conversation with a customer. Our Salesforce consulting services team builds these into the design rather than reconstructing them after a complaint.
It determines which source records describe the same person, then merges them into a unified profile. It runs through a configurable ruleset with two parts: match rules that decide which records belong together, and reconciliation rules that decide which value appears on the merged profile.
Match rules answer "are these the same person?" Reconciliation rules answer "which value wins?" You need both configured deliberately. Tuning match rules while accepting reconciliation defaults is the most common half-finished implementation.
Not as a configurable match method. Data Cloud offers exact, exact normalized, and fuzzy matching. Probabilistic matching is a general industry concept, and it gets misattributed to the product regularly — including in the earlier version of this post.
Yes. Data 360 is the current official name; Data Cloud is what it was called before. Nothing in identity resolution changed with the rename. Carry both names, because tenders will use the old one for years.
Read the merged profiles, not the match rate. Sample twenty new merges and check each is defensible. A rising match rate with indefensible merges is the signal to stop widening.
Yes, in practice. An agent grounded on duplicates gives partial answers. An agent grounded on over-merged profiles gives one customer another customer's information. Our post on turning unified profiles into agent action covers that dependency.
Identity resolution is not difficult because the feature is complicated. It is difficult because the configuration has consequences that surface months later, in systems nobody connected to the rule that changed. Minuscule Technologies works as a Salesforce engineering partner, not a configuration service. We design, deploy, and operate identity resolution with the discipline the blast radius deserves — new implementations, remediation of rulesets that merged too much, and cleanup where profiles are already trusted and should not be.
Three things shape how we deliver. Our Accelerators and Starter Packs supply what every build needs: validated match rule templates by industry, reconciliation decision matrices, identifier-uniqueness audit scripts, and consent-safe activation patterns. Our Agentic DevOps practice treats the ruleset as a deployable artifact, so a match rule change moves through a sandbox, a validated diff, and a reviewable promotion instead of a click in production. And our re-engineering work rebuilds identity resolution configured before the data model was ready, with match quality and consumption cost as the two numbers we report against.
Book a free identity resolution review. We will audit identifier uniqueness across your sources, sample your merged profiles for indefensible matches, test what your consent handling does through a merge, and tell you what a rule change would break downstream. It takes about a week, there is no obligation, and the findings are yours either way. Schedule your strategic Salesforce call and start with an audit instead of a match-rate target.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
