Single Customer View: Can Records Be Matched?
Imagine a customer who changes an email address, buys through a store, and later calls support. The store may have a transaction under a loyalty number, the service team may have a case under a phone number, and the marketing system may still hold the old email. Someone looking at one system sees only part of the relationship. Someone looking at a carelessly combined record may see somebody else’s information as well.
That is the practical problem behind a single customer view: deciding which records refer to the same customer, keeping the useful information connected, and showing a person enough context to act correctly. It is tempting to treat the job as copying every available field into one large row. The hard decision comes earlier. A system must decide whether two records belong together, and it must be able to revise that decision when the underlying information changes.
I would build the view around a specific use, such as helping a service representative recognize the customer’s recent interactions. I would then connect the minimum relevant sources and keep the route back to each original record. A wider collection of data can wait until there is a clear purpose for it. This approach costs some up-front work in selecting fields and writing match rules, but it makes an incorrect match easier to spot and correct.
A single view is a resolved identity with its source records still attached
In customer data unification, the inputs are records from different systems. A process selects source data, maps fields, removes duplicates within a source, matches records across sources, and produces a unified profile. Microsoft describes those as distinct steps in its data unification process. The finished profile is a useful point of access, but it is the result of decisions about source records rather than an independent fact about the customer.
Consider a simple illustrative case. A CRM contact has a name and current email. An online account has the same email and a different spelling of the name. A service record has a phone number and a case history. The view might connect all three, but only if the matching conditions justify doing so. The account’s purchase or service history should remain tied to the appropriate underlying record; an employee should be able to see where a displayed value came from. Salesforce describes link tables that retain the relationships between unified individuals and original data. That relationship is central to a trustworthy view: one display can draw on several records without pretending that the records have become one original record.
This distinction also helps explain why a single customer view is more than a screen in a CRM. A CRM contact can be an excellent source and may already be the best starting point for a service team. Yet if the task involves an account record, a store record, and a service record held elsewhere, a contact page alone does not settle which records refer to the same person. Conversely, a unified profile does not automatically make every downstream screen useful. The screen still needs to show the facts required for the decision at hand, with enough context to interpret them.
The word single describes a way to find and use connected information. It should not be read as a promise that every field has one permanent, universally correct value. An address can be a shipping address in one source and a contact address in another. A phone number can become outdated. If a view collapses those distinctions, it can be visually tidy while giving the wrong answer to the employee who uses it.
Decide whose view it is before deciding what to merge
The first design choice is the unit represented by a profile. For an individual customer service journey, that unit may be a person. For an account management task, an organization and its contacts may need separate identities with a relationship between them. A transaction, support case, or address is not automatically another customer. The choice matters because the matching process will group source records according to the identity it has been told to construct.
Start with a question that can be answered at the moment of use: “Which of these records belong to the person speaking to support?” or “What information may a service representative use to understand this customer’s issue?” Those questions lead to different fields and different tolerance for uncertainty. A misplaced marketing message and a support agent revealing another person’s case are different errors. If the view will be used for both, the matching rule and the information shown to each user should reflect the more consequential use.
The source record also needs a clear meaning. Microsoft’s guidance for its unification process distinguishes profile data such as name, phone, and address from customer activity data such as purchases with a one-to-many relationship to a customer; it says to select the former for profile unification and handle activities separately. Its guidance also recommends reviewing source data and removing unwanted rows before unification. That distinction between profile records and activities prevents a purchase from being mistaken for another person merely because it contains a customer identifier.
In practice, I would write down the use of each proposed field before importing it into a shared profile. An email may help link accounts and may also be a contact address, but those are two separate uses. A transaction ID can connect a purchase to its source record; it is a poor substitute for evidence that two personal profiles belong to the same individual. A support note may be relevant to the current case without becoming an all-purpose profile attribute. These distinctions keep the customer view close to the decisions it is meant to improve.
Source selection and mapping set the ceiling on the result
Matching rules cannot recover meaning that was discarded when sources were prepared. If one system records a current email, another holds a historical email, and both are mapped into a field called “email” without any indication of status, the final view may look consistent while concealing an important difference. Source selection should therefore begin with the records needed for the stated use, followed by the meaning of their fields, their identifiers, and the way changes reach the view.
The first pass should favor sources with clear ownership and useful identifiers. If a service agent must connect a support case to an account, the account and service systems have a direct reason to be present. A web record should be added when it helps answer the same question and when its identifiers can be interpreted. Adding an entire new source merely because it exists increases the number of comparisons and possible conflicts without necessarily helping the user.
Mapping makes unlike source columns comparable. A CRM column called primary_email and an account column called login_email may both contain email addresses, but their names signal different functions. The mapping can describe both as email fields while preserving which one is a login and which one is a contact preference. Microsoft’s process requires mapping source columns to descriptive types before deduplication and matching, then choosing which fields to include, exclude, or merge in the unified view. The point is not to force unlike data into a common label. It is to make comparison possible without losing its source meaning.
Deduplication within a source comes before cross-source matching in that process. This order matters. If a CRM has two rows for the same customer, sending both onward as separate candidates can make the final output look more fragmented than the source really is. But a duplicate rule can also combine people who happen to share a value. I would inspect the kinds of duplicate the source actually contains, choose the best row to represent each group, and retain access to the rows that were grouped. The cost is time spent understanding source quality before the unified profile becomes visible. The benefit is that the later match rules operate on a clearer set of candidates.
Matching is a decision with two ways to be wrong
Identity matching asks whether two source records refer to the same customer. In Microsoft’s implementation, a team orders source tables and defines conditions for each pair of tables. Conditions can use selected fields, normalization, precision settings, and exceptions; the order of rules matters because the system tries the first rule before later ones. Its guidance recommends a primary table with complete, reliable profile data and fields in common with other tables. Those details of match order and rule construction show why “match on email” is rarely a complete design description.
Normalization makes values comparable despite formatting differences. For example, Microsoft documents options that change text case, remove whitespace, normalize phone formats, and map known aliases. That can help a record with a differently formatted phone number match another record. It cannot establish that whoever supplied that phone number is the same person. A shared number, a recycled value, or a placeholder entered in many records may make a broad rule unsafe. Microsoft’s documented bypass option can exclude values such as a dummy phone number from matching; its exception rules can prevent records from joining when other fields contradict the proposed link. The normalization and exception options are ways to express actual distinctions in the data, not a reason to relax every match.
The first error is a false positive: records from different people are joined. Microsoft’s example of twins with the same last name, city, and birth date illustrates the point. A rule using those three fields may need a first-name exception to keep the profiles apart. The second error is a false negative: records for the same person remain separate. Microsoft explicitly describes both as possible outcomes of matching rules. Its match-rule guidance treats precision and exceptions as choices because neither error disappears by selecting a single matching field.
An illustrative changed-email case shows the trade-off. Suppose one source holds a customer’s former address and another holds the new address. Requiring an exact email match would leave the two records apart unless another permitted field or a known relationship links them. A very permissive name match might join them, but it might also join a different person with the same name. I would accept an unresolved pair until there is a stronger connection when the view may expose service details. If the purpose is a less sensitive aggregate count, the acceptable decision may differ, but the team still needs to state what a mistaken link would do.
This is why the source population matters more than a slogan about a “360-degree” customer. A rule that works on one set of source records may behave differently after a new table is added or source practices change. There is no honest universal match percentage in the supplied material, and no basis for claiming that one chosen threshold is best for every source. The useful question is whether the chosen fields and exceptions distinguish customers in the records that actually feed this view, at the time it will be used.
Reconcile values without erasing disagreements
Matching decides which records belong to a unified identity. Reconciliation decides which values appear in the unified profile. Salesforce describes the two operations separately: identity rules group source profiles, while reconciliation rules select the values for the resulting profile. It also describes keeping links to the source data. That separation of matching and reconciliation is essential because two records can correctly belong to one person and still disagree about an attribute.
Imagine a customer whose CRM contact lists one phone number and whose online account lists another. A single “best phone” field might be convenient for a call queue, but the right value depends on what each number means and how the organization learned it. A newer value is not automatically the right service contact; an older value is not automatically useless. The view can select a preferred value for a particular use while still showing the alternatives and their origins when that difference matters.
I would choose a value rule field by field. For a display name, a verified account source might be suitable if that is where the customer maintains the name. For a shipping address, the most recent order may be relevant to the order being discussed, while an account address may be relevant to future shipments. Those are illustrative choices, not universal rules. If the organization cannot say which source is authoritative for a field and under what conditions, it should show the disagreement rather than give one value the appearance of certainty.
The same reasoning applies to missing values. A blank in one source can mean “not collected,” “unknown,” or “removed”; it does not by itself disprove a value in another source. The unified profile should make the chosen display useful while retaining enough source context to revisit the choice. In a support interaction, the most valuable part of a view may be a clear statement that two systems disagree, followed by the original records that explain the difference.
Keep activities connected without turning them into profile fields
A customer can have many purchases and many service cases. Turning each activity into a person-level field creates a brittle picture: which purchase is the “purchase,” and what happens when another arrives? Microsoft advises keeping one-to-many customer activity data out of the profile-source selection during unification. Its unification overview then points to relationships, activities, and measures as ways to use information associated with the resulting profiles. That profile-versus-activity design supports a more useful screen: a stable customer identity with relevant events attached.
For a service representative, the screen might display a small set of linked cases and orders with their own dates and identifiers. The illustrative design question is not whether to copy every line of every order into the profile. It is which linked events help the representative understand the current request and how the representative can open the original record. This approach keeps event detail in the system or table where it belongs and avoids making the profile a competing transaction ledger.
That separation also helps when a match changes. If two personal profiles were incorrectly joined, the organization must be able to tell which source records and related activities belonged to each profile. Salesforce’s link-table description and Microsoft’s merge-and-split behavior show that a unified identity has relationships to underlying records and can change as source data or rules change. The retained source links are therefore part of the working design, not a technical detail that can be discarded after a screen is populated.
Treat the customer ID as durable enough to use, but capable of changing
A unified profile usually needs an identifier so other systems can refer to it. Microsoft says its unification process assigns a CustomerId and normally preserves it between runs, with stated exceptions for merges and splits. When two profiles merge, one previous ID is generally used; in some circumstances a new ID may be assigned. When one profile splits, one resulting profile retains the old ID and the others receive new IDs. The product also exposes a PreviousCustomerId field for those changes. Microsoft’s description of merge and split behavior makes an important operational point: even a well-managed unified ID is an output of changing data and rules.
That means a downstream team should know what a merge or split does to its own references. If a service workflow stores a unified ID beside a case, a later split must not leave the case permanently associated with the wrong person. If a marketing list uses the unified ID, a merge could change which source records are included in the next run. The exact handling depends on the systems involved, but the design requirement is clear: preserve the source identifiers and a way to follow identity changes so a mistaken grouping can be corrected.
I would avoid treating the first unified profile as an irreversible master record. A customer may update an identifier, a source may correct a row, or a rule may be refined after an ambiguous match is noticed. The preferred path is to let the view evolve while preserving the history needed to explain why a record moved. That takes more work than an export of a single flattened table. It also makes the view usable after the inevitable correction.
Use the view for a decision, then expand its reach carefully
A single customer view is valuable when it changes what someone can do at a decision point. A service representative could recognize that two cases and an account record belong to the same person. A team preparing a customer communication could avoid treating two linked source profiles as separate people. These are illustrative uses of the resolved identity; the sources establish the unification and linking mechanisms, not a measured outcome for any particular organization.
I would begin with one such use and describe the minimum information the user must see: the identified customer, the source of each displayed value, the relevant linked activities, and any unresolved conflict. That is a stronger specification than “show everything we know.” It tells the data team which sources to connect and gives the person using the screen a reason to trust or question what appears there.
The next use may justify another source or a different view of the same linked records. Salesforce describes unified data feeding segments, insights, reporting, and actions in its Data 360 architecture. Those possibilities do not mean every source field should be made available to every use. A service screen, an analytic count, and an outbound communication have different needs. Reusing a resolved identity can be sensible, but each new use still needs its own choice of fields, rules, and access.
This also shapes the choice between relying on an existing CRM record and introducing a separate unification layer. If the task is fully answered by one reliable source, the extra matching work may add little. If the task requires connecting independent records whose identifiers and attributes differ, a process for mapping, deduplication, matching, reconciliation, and source links has a clear purpose. The material here does not establish a universal platform choice or price comparison. The decision turns on the organization’s sources, the consequence of a wrong link, and the actions the view must support.
A useful view still has limits on what it should collect and show
Connecting records increases the amount of personal information accessible from one place. That creates a reason to decide the view’s purpose and scope before collecting fields. The UK Information Commissioner’s Office describes purpose limitation, data minimisation, accuracy, storage limitation, security, and accountability among the UK GDPR’s data protection principles. In that framework, personal data should be adequate, relevant, and limited to what is necessary for its purpose. A customer view designed for a service interaction therefore should not absorb unrelated personal data merely because a connector can reach it.
Accuracy matters especially when identity rules can join the wrong people. If the match is uncertain, a screen should not quietly present another record as settled fact. Keeping source links and making correction possible are practical ways to address the accuracy problem within the unification design. Retention and access also deserve explicit choices: a view that helps with a current service case does not automatically need old data indefinitely, or need to expose every linked detail to every employee. The ICO’s principles give the direction; the exact obligations depend on the processing context and jurisdiction.
The cost of restraint is that some apparently interesting data remains outside the view until a use is defined. That is a reasonable cost. A narrow view can be expanded when a real decision requires it. A broad profile that has already combined unnecessary fields is harder to interpret and harder to correct when an identity link proves wrong.
Build the first version around a case you can explain
The first version should be small enough that a team can trace a displayed value back to its source. Choose a concrete use, identify the person or account the view represents, and select the source records needed to answer the user’s question. Map fields without hiding their roles. Remove unwanted source rows, deal with duplicates within each source, and then set cross-source match conditions. This follows the order described in Microsoft’s unification guidance, but the same reasoning applies even when the implementation is different.
Before broadening the rules, examine ambiguous pairs. What would make two records the same person? What would make them different? A shared last name, city, and birth date can be insufficient in Microsoft’s twins example; a dummy phone number should be ignored as a match value. Those documented exceptions are a reminder to write rules for actual source values, including the values that should never create a link. Where the source data cannot settle an identity, it is better to preserve separate profiles than to present a confident but unsupported merge for a sensitive use.
Then choose which values appear in the resulting profile and which remain available as alternatives. Keep the source relationships, because a displayed address or phone number without origin may be misleading. Plan for the moment when a source update causes two profiles to merge or one to split. The view is ready for its first use when a person can see the relevant customer information, understand where it came from, and recover from a wrong connection without losing the original records.
The strongest single customer view is therefore not the one with the most fields. It is the one that links the right records for a stated purpose, keeps their meanings intact, and allows the identity decision to change. That is what makes one view useful to a person who must act on it.