Skip to main content
Group

Salesforce Duplicate Management

This group is for customers, partners and Salesforce employees to discuss and provide feedback on the Duplicate Management capabilities from Salesforce.

I discovered we have thousands of these. Can they and their related Duplicate Record Item be deleted? I'm pretty sure it's because one of our managed packages has a custom dupe management process, and when that is used the single Duplicate Record Item in the Set is not auto-deleted.

3 answers
  1. Apr 10, 5:25 PM

    I'm a little late to the party, but I solved this by creating a Triggered Flow on the DuplicateRecordSet object to fire "On Update". The Entry Condition is set to "Record Count Less Than or Equal 1" with the "Only when a record is updated to meet the condition requirements" selected. I added a Delete element configured to delete the "Triggering DuplicateRecordSet" 

     

    This works because the Record Count field is a Roll-Up Summary and RUS do fire update triggers when their value changes. 

0/9000

We have enabled Duplicate Rules in our sandbox. Ran the Duplicate Job on Lead and Person Account using OOTB duplicate and matching rules and created report type for Duplicate Record Sets. 

  • When a specific user with Salesforce and Sales Console User licensed and Minimum Access profile is trying to access the Duplicate Record Set list view, they cannot see the records. 
  • We created a report  using custom report type and when user tried to access a record from the report, they cannot see any details on the record page.

Not sure why. No problem with users with Standard User profile. User has CRUD access to Lead, Account, Contact and Duplicate Record Set objects.

Attaching screenshots for reference. User cannot see details of Duplicate Record Set recordIssue-DuplicateRecordSet-2.pngIssue-DuplicateRecordSet-3.png

8 answers
  1. Mar 6, 7:50 PM

    I had a particular issue where users could see all Duplicate Record Set fields, except for 'ParentId' (commonly used in reports). To get access to it, the users should have the 'View Setup and Configuration' permission.

0/9000

Hello, 

 

I'm looking for a custom solution to identify duplicate records across Contacts and Leads in my organization. Although duplicate rules can match across objects, a duplicate job will only run for the object defined in the matching rule. I understand there are paid options to accomplish this at scale, but I'm curious if anyone has successfully implemented a custom solution to accomplish this. At this stage, I'm simply looking to identify the number of duplicates I have across both objects. Any help or guidance is much appreciated. 

 

Thank you, 

Will 

3 answers
  1. Jan 16, 5:46 PM

    Hi Will, 

     

    The other answers show how to use very simple fuzzy matching rules, which work on many cases but are notorious for false positives and false negatives. 

     

    Since you ask if anyone has implemented a custom solution to this - I have! I have been working to find a way to use LLMs to do deduping, but very cheaply. It's at

    everyrow.io/dedupe

    . It's free up to a few hundred rows to try it out. 

     

    On of my coworkers wrote up a case study on salesforce contacts specifically that we dealt with, which looks a lot like your problem, which is how I found your post. Maybe you'd find it helpful. 

    https://futuresearch.ai/researcher-dedupe-case-study/

     

    Good luck, 

    -Dan

0/9000

Concept is simple: Think of companies with multiple store locations (like Starbucks) – there are multiple locations in a single city, but these Accounts are not duplicates -- the account name is similar, but the store number is unique.

We want fuzzy match on account Name to assist with preventing duplicates on account creation.  However we want the  matching rule to not-make-a-match if the Store Number value is different.  (Store Number field on the account is unique)

 

We essentially want to be able to have the Matching rules IGNORE the fuzzy match on Account Name if the values in Store Number field are different, but not blank.  

 

Example:

Existing Account:  Name = "Freeman, Inc"  Number = "1234"

New Account 1:  Name = "Freeman, Inc"       Number = "5678" --> desired result: No Match

New Account 2:  Name = "Freeman"             Number = blank --> desired result:  Match

 

Is there a way to do this with the standard Matching/Duplicate rules in Salesforce that we are simply overlooking?

4 answers
0/9000

We use NPSP, currently there are 3 emails fields, Personal Email, Work Email, Alternate Email. When creating matching rules, we need to create matching rule for each email field separately. Ideally, when importing Contacts, Salesforce should be able to match the email in the import file across all the fields. I can create an apex trigger to block duplicate record creation based on email addresses across all the 3 fields. But I think this is an unnecessary thing to do. This can be easily done if Salesforce allows multiple fields from the Contact object to be mapped in the matching rule. Currently Salesforce allows the same object only once in a matching rule. 

If anyone experienced the same issue and if could add a comment to let me know how you have resolved the issue, that would be great.

0/9000

Hi! We're struggling with duplicate management, specifically matching rules and different record types. Mainly in leads and person accounts. Wanted to ask if someone has had similar issues and how you solved them? 

 

E.g. We have 6 record types for leads and 4 record types for person accounts. They don't have anything to do with each other, so leads with different record types are not duplicates. However, we're not able to use record type as a criteria for matching rule, to my understanding. 

We're also not able to use 'Type' as a criteria as we have leads with different types, that 

are

 duplicates.  

 

We have solved this with a custom text field where we add a record type name with a RT before-save flow when lead or person account is created. We also use this cross-object, for leads & person accounts with the same record type. However, this is not working too well, the duplicates aren't always recognized when records are created. 

0/9000

When completing a merge in Lightning, not all of the fields display as they do in Classic.  Is there a way to customize or add fields?  There is one specific custom field that does not display, but is important to us in determining which to keep.

1 answer
0/9000

Any suggestions for how to create a matching rule for street addresses that will not match on truly different addresses that only vary by the directional N, S, E or W? e.g., 110 James Dr W Vs. 110 James Dr E   I'm currently using Street: Fuzzy match, and it also matches on East Vs. West, but those really shouldn't match. The resulting problem is that users are blocked from creating the 2nd address and have to request an Admin to temporarily turn off the duplicate rule, which can lead to delayed sales.

 

I know why it is matching, because the algorithm works based on a weighting of the components of the address, and in this case, with East vs West being the only difference, it must have unfortunately determined that the entire street addresses match 80% or more.

The following is from Salesforce Help:

Matching Methods Used in Matching Rules (https://help.salesforce.com/s/articleView?id=sf.matching_rules_matching_methods.htm&type=5) 

Addresses are broken into sections and compared by those sections. Each section has its own matching method and match score. The section scores are weighted to come up with one score for the field. This process works best with North American data.

  • Street Name (Edit Distance, 50% of field’s match score)
  • Street Number (exact, 20% of field’s match score)
  • Street Suffix (exact, 15% of field’s match score)
  • Suite Number (exact, 15% of field’s match score)

For example, these billing streets are being compared: 123 Market Street, Suite 100, and 123 Market Drive, Suite 300. Only the street number and street name match, so the field has a match score of 70. This score isn’t considered a match because it falls below the threshold of 80.

 

What percentage is the directional weighted? In my opinion, it should have a large weighting. Any ideas for a workaround so that addresses with different directionals don't match?

1 answer
  1. Eric Praud (Activ8 Solar Energies) Forum Ambassador
    Jun 17, 2024, 12:35 PM

    Hi,

     

    You could probably create another field and you would update it with the directional through a record triggered flow every time an address is entered or changed.

    Now, in your matching rule, you could add a line so that this field needs to be an exact match 

0/9000

We recently added a new duplicate rule to compare leads to contacts, and it is activated but in it is only running against newly created or edited records. It isn't an option in Duplicate Jobs because it is a cross object duplicate rule. Is it possible to force this rule to run in SFDC (without a 3rd party application)?

1 answer
  1. Evaldas Zaranka (Wise) Forum Ambassador
    May 24, 2024, 3:45 PM

    Hi, 

     

    Without third-party tools like Apsona I don`t think it`s possible 

0/9000
  • I have 2 leads that are identical but owned by different people
  • There is a private sharing model in place - the lead owners can only see leads they own
  • A duplicate rule is running on the lead object with bypass sharing rules
  • When either of the lead owners view their leads, no duplicate is flagged by the potential duplicates standard Lightning component - I know there are duplicates and expect them to be flagged
  • A potential duplicate is flagged if any of the fields that trigger the matching rules are edited - this is what I'd expect
  • When either lead is viewed by a manager who can view all leads, the potential duplicates component now does warn of the duplicates

I've attached views of:

  • duplicates correctly being flagged for the manager 
  • a regular user seeing one message saying there is a duplicate and another saying there are none

This is pretty confusing and needless to say we're having problems with duplicates being contacted because these aren't being flagged where leads come in with all details that trigger matching rules already populated. 

 

Does anyone else get this behaviour or feel this is correct?

 

Logged in as lead owner

Why does the Potential Duplicates component not work with private sharing, even when bypass sharing rules is enabled?

 

Logged in as manager

Manager viewing - correct.png

9 answers
0/9000