Admins / Data / Data Cloud

Intentional vs. Unintentional Duplicates in Salesforce

By Mehmet Orun

Not all Salesforce duplicates are inherently bad. Nor does having duplicate records necessarily indicate poor data quality in your org. Salesforce Ben and others have extensively covered methods for identifying (matching) and merging  Salesforce duplicates. But what if you can’t, or don’t want to, merge records?

In this blog, I’ll describe the difference between intentional and unintentional CRM duplicates and provide best practices for how to deal with them.

Duplicates: Good or Bad?

For this discussion, let’s define duplicates as multiple records that represent the same entity. This could be a prospect with multiple lead and/or contact records, or multiple account records representing the same organization.

There are legitimate data governance reasons for having duplicate records in Salesforce. So how can you tell if you have good or bad duplicates? The key is to understand why the duplicate was created in the first place.

Unintentional Duplicates

We see unintentional duplicates in Salesforce when there are two or more records about the same entity in the same business context. This could be:

  • Multiple lead records for the same individual with the same email, due to different data sources or automated record creation processes.
  • Two account records with the business name spelled differently (IBM vs. International Business Machines).
  • Two accounts with one at a previous address and another at the current address.

Unintentional duplicates are bad for businesses because they waste time and obscure the full context of the relationship with the entity. Users tend to start at a single customer record to find all related transactions and engagements. Having related activities spread across duplicate records makes it difficult for users to get the full picture. They have to spend extra time searching for the information they require. 

Ironically, one of the most common reasons for unintentional duplicates is existing unintentional duplicates; users do not know the right record to use, so they create another.

Intentional Duplicates

Intentional duplicates are a deliberate choice. They are the result of needing multiple records for the same entity to serve different business purposes. The need for different data access controls or even different data classification rules can also necessitate intentional duplicates.

Although some records may share the same name, contact points, and external identifiers, there are valid reasons to keep them separate. For example:

  • An employee-maintained customer record in Sales or Service Cloud vs. a self-service maintained record in Experience Cloud.
  • A business that is both a customer and supplier could have two account records to represent each relationship.
  • Multiple account records for different locations of the same organization – there is a common debate about whether these are duplicates or not, with the usual answer being “It depends”.
  • A consultant with a client contact record for acting on the client’s behalf, as well as a business contact record as part of their employer’s account.

As an Experience Cloud user, I would not want a service agent’s data entry to impact how I have chosen to spell my own name.

Users with access to customer records may not have permission to see supplier records. Segmentation and tiers may be also different for customers and suppliers.

Related Records vs. Duplictes

What about two different records about the same individual? As people change jobs, you may have the same individual associated with multiple accounts and opportunities. For example: 

NameCompanyEmailLinkedIn URL
Mehmet OrunSalesforce, Inc.morun@salesforce.comin/mehmetorun/
Mehmet G. OrunPeerNova, Inc.morun@peernova.comin/mehmetorun/

In the above example, using matching rules, you can identify they are both related to the same individual, in this case, me.  However, company names and email domains are distinctly different, indicating they are likely for different contexts.

Is it helpful and/or important to understand relationships across related records? Absolutely.  As a business, you want to understand your relationships with individuals as well as organizations, not just business contacts and account records.  

You should never merge related records… so how do you identify the relationship? Let’s talk about Unified Profiles.

Unified Profiles

While data governance may require keeping records separate, users still need a single, unified view of the entity and all its related transactions. This is where unified profiles come in. Unified profiles bring data from multiple distinct records and related information together as one representation of the entity, linking past engagement while maintaining context and compliance. 

Historically, Master Data Management platforms were the go-to choice for building unified profiles, often referred to as Golden Records.  Frankly, these did not deliver the desired business outcomes most of the time as organizations need to maintain different contexts while building unified profiles from a single source of truth. 

Today, we can use Data Cloud to create unified profiles, use key rings and data spaces to build contextual and compliant views based on consistent, complete, and correct data,  and maintain simpler control of our information. It is worth noting the two approaches are distinctly different, and I for one prefer Data Cloud’s approach.

Getting back to the above example, with Data Cloud, you can have a single unified profile for me and identify which attributes can have only one valid value at a time through reconciliation rules (e.g. current employer). Then keep all related records, well, related! You’d know I worked for Salesforce and now work for PeerNova. 

Duplicate Management Best Practices

Do develop data governance policies that outline when intentional duplicate records should exist. Document the data attributes you will use to classify distinct business relationships and identify intentional duplicates in the CRM. Record types are great for making intentional duplicates clear.

Do understand how different matching algorithms work to make sure you use the right approach for the right business need (e.g. unintentional duplicate detection/prevention vs. reliable profile unification).

Do profile your data as a pre-requisite step to configuring comprehensive matching rules. Also, use profiling to identify and scrub fake/bad data that will negatively impact your matching results.

Do use external identifiers to identify intentional and unintentional duplicates. Use entity identifiers from data enrichment providers, such as DUNS Number from Dun & Bradstreet for account matching. Use LinkedIn profiles to identify business contacts as the same person.

Do recognize duplicate detection and handling is not a one-time exercise. As records are updated over time, you may be able to identify two or more records as duplicate or related, and at times no longer related.

Do use unified profiles to give users a single, compliant view of intentional duplicates and related records.   

Do engage the data governance process to determine how to handle instances of the same individual across different business relationships. For example, Sam Smith was a customer at Company A and now works at Company B. Consider if Contacts to Multiple Accounts will work for your organization. If loss of information may create compliance and data security risks, maintain intentional duplicates.

Do not assume record merging is the only way to handle unintentional duplicates.  Unmerges are difficult and expensive. The goal of handling unintentional duplicates is to provide a consistent, complete, and correct view of your relationships. Starting with unified profiles will accelerate and derisk your duplicate management efforts.

Do not over-merge records, just because they have overlapping attributes. Maintain intentional duplicates as separate records per governance policies.

Final Thoughts 

Duplicate management is an important component of Salesforce data quality, but the goal is not to merge every duplicate. Instead, seek to provide users with a single, complete view of all related information while honoring the data compliance and security needs of your org. 

By embracing these strategies, architects and admins can optimize their Salesforce orgs to effectively support business operations.  

The Author

Mehmet Orun

Salesforce Veteran and Data Management SME, working with Salesforce since 2005 as a Customer, Employee, Practice Lead, and Partner. Now GM and Data Strategist for PeerNova, an ISV partner focused on data reliability, as well as Data Matters Global Community Leader.

Comments:

    Josh Rojas
    April 13, 2024 11:05 am
    Dont forget the (system intentional) duplication of account and contact records for person accounts :D

Leave a Reply