Aptitude (12) C (2) C++ (10) CSS (1) Data Structure (2) English (7) General (14) HTML (3) Integration (1) Itinerary and Travel Cost (1) Java (29) JQ (5) JS (5) JSP (1) Lightning (14) logical (3) Math (1) Music Notation (17) MySql (4) Network (1) Regex (1) salesforce (131) Servlet (4) SF Admin (31) SF Dev (102) SQL (4) SQL_SERVER (1) StudyPoints (2) ytChannels (2) अन्ताक्षरी (4)

Duplicate Management


  1. Matching Rules
  2. Duplicate Rules
  3. Duplicate Record Sets
  4.  Duplicate Error Logs

What Are Matching Rules?

A matching rule compares field values to determine whether a record is similar enough to existing records to be considered a duplicate. 

For example, a matching rule can specify that if the Email and Phone values of two records match exactly, the records might be duplicates. 

Use matching rules with duplicate rules to define what happens when duplicates are identified.
After a matching rule is activated, one or more match keys are automatically created and applied to existing records. (Also known as indexing, this process improves performance and returns a better set of match candidates because the matching rule is only looking for duplicates among records with the same match key.) When the matching rule is run, it compares the record’s match keys against those for existing records. Then, for records that share the same match keys, the matching rule uses matching algorithms to compare fields and determine how closely the fields, and ultimately the records, match. If two records’ don’t share the same match keys, they are not considered duplicates and the matching algorithms will not even be applied to them. 

Standard Matching Rules

We’ve provided several standard matching rules that you can use with Data.com Duplicate Management tools, such as duplicate rules. Each standard matching rule has been carefully designed to return the best possible set of match candidates for accounts, contacts, or leads.



When you create a custom matching rule, you need to define certain criteria. For standard matching rules, the criteria are already defined for you.

Rule NameMatching Equation
Standard Account Matching Rule(Account Name AND Billing Street)
OR (Account Name AND City)
OR (Account Name AND ZIP)
OR (Account Name AND Phone)
OR (Website AND Phone)
OR (Website AND Billing Street)


FieldMatching AlgorithmsScoring MethodThresholdBlank FieldsSpecial Handling
Account NameAcronym
Edit Distance
Exact
Maximum70Don’t matchRemoves words such as Inc and Corp before comparing fields. Also, company names are normalized. For example, 1st National Bank is normalized to First National Bank.
PhoneExactWeighted Average80Don’t match on all sections expect Area Code, which ignores blank fieldsPhone numbers 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 1 score for the field. This process works best with North American data.
  • International code (Exact, 10% of field’s match score)
  • Area code (Exact, 50% of field’s match score)
  • Next 3 digits (Exact, 30% of field’s match score
  • Last 4 digits (Exact, 10% of field’s match score)
For example, suppose that these two phone numbers are being compared: 1-415-555-1234 and 1-415-555-5678.
All sections match exactly except the last 4 digits, so the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
Billing StreetEdit Distance
Exact
Weighted Average80Don’t matchAddresses 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 1 score for the field. This process works best with North American data.
  • Street Number (Exact, 20% of field’s match score)
  • Street Name (Edit Distance, 50% 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, suppose that these two billing streets are being compared: 123 Market Street, Suite 100 and 123 Market Drive, Suite 300.
Because only the street number and street name match, the field has a match score of 70, which is not considered a match because it’s less than the threshold of 80.
ZIPExactWeighted Average80Don’t matchZIP codes 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 1 score for the field.
  • First 5 digits (Exact, 90% of field’s match score)
  • Next 4 digits(Exact, 10% of field’s match score)
For example, suppose these 2 ZIP codes are being compared:94104–1001 and 94104.
Because only the first 5 digits match, the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
CityEdit Distance
Exact
Maximum85Don’t match
WebsiteExactMaximum100Don’t matchThe prefix “http://” is appended to the website domain. For example, a field value www.salesforce.com becomeshttp://www.salesforce.com for matching purposes. Matching for an account record that has a website without the “http://” prefix identifies the record as a duplicate.

Standard Contact and Lead Matching Rule

Like all matching rules, the standard matching rule used for contact and lead records is made up of fields that are arranged into an equation. Each field also contains matching criteria that the rule uses to determine how closely the field matches the same field in an existing record, and ultimately whether the record is a match.

Matching Equation

Rule NameMatching Equation
Standard Contact Matching Rule
Standard Lead Matching Rule
(First Name AND Last Name AND Title AND Company Name)
OR (First Name AND Last Name AND Email)
OR (First Name AND Last Name AND Phone AND Company Name)
OR (First Name AND Last Name AND Mailing Street AND (City OR ZIP OR Phone)
OR (First Name AND Last Name AND Mailing Street AND Title)
OR (First Name AND Last Name AND Title AND Email)
OR (First Name AND Last Name AND Phone )

Matching Criteria

For a definition of each matching criteria, see Matching Criteria for Matching Rules.
Fields on ContactsFields on LeadsMatching AlgorithmsScoring MethodThresholdBlank FieldsSpecial Handling
First NameFirst NameExact
Initials
Jaro-Winkler Distance
Metaphone 3
Name Variant
Maximum85Don’t match (Ignores blank fields when Email is included in field grouping)If record contains a value for the both First Name and Last Name fields, those values will be transposed to account for possible data entry mistakes.
For example, if the first name is George and the last name is Michael, the matching rule will also evaluate first name as Michael and the last name as George.
Last NameLast NameExact
Keyboard Distance
Metaphone 3
Maximum90Don’t match (Ignores blank fields when Email is included in field grouping)If record contains a value for the both First Name and Last Name fields, those values will be transposed to account for possible data entry mistakes.
For example, if the first name is George and the last name is Michael, the matching rule will also evaluate first name as Michael and the last name as George.
TitleTitleAcronym
Exact
Kullback-Liebler Distance
Maximum50Don’t match
Account NameCompanyAcronym
Edit Distance
Exact
Maximum70Don’t match
EmailEmailExactMaximum100Don’t match
PhonePhoneExactWeighted Average80Don’t match on all sections expect Area Code, which ignores blank fieldsPhone numbers 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.
  • International code (Exact, 10% of field’s match score)
  • Area code (Exact, 50% of field’s match score)
  • Next 3 digits (Exact, 30% of field’s match score
  • Last 4 digits (Exact, 10% of field’s match score)
For example, suppose these two phone numbers are being compared: 1-415-555-1234 and1-415-555-5678.
All sections match exactly except the last 4 digits, so the field has a match score of 90, which is considered a match because it exceeds the threshold of 80.
Mailing StreetStreetExactWeighted Average`80Don’t matchAddresses 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, suppose these two addresses are being compared: 123 Market Street, Suite 100 and 123 Market Drive, Suite 300.
Because only the street number and street name match, the field has a match score of 70, which is not considered a match because it’s less than the threshold of 80.
Mailing ZIP/Postal CodeZIP/Postal CodeExactWeighted Average80ZIP codes 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.
  • First 5 digits (Exact, 90% of field’s match score)
  • Next 4 digits(Exact, 10% of field’s match score)
Mailing CityCityEdit Distance
Exact
Maximum85Don’t match

Matching Criteria for Matching Rules

Matching rules use criteria to determine how closely a field on a new or edited record matches the same field on an existing record, and, ultimately, whether the two records are duplicates. When you create a custom matching rule, you need to define certain criteria. For standard matching rules, the criteria are already defined for you.
Available in: Salesforce Classic and Lightning Experience
Available in: ProfessionalEnterprisePerformanceUnlimited, and Developer Editions
CriterionDefinitionAutomatically Defined for Custom Matching Rules
FieldIndicates which field to compare. When selecting fields, keep in mind that:
  • The available fields depend on which object the matching rule applies to and include both standard and custom fields.
  • The supported input field types are email, lookup relationship, master-detail relationship, number, phone, standard picklists, custom picklists (single-select only), text, and URL.
  • An auto-numbered lookup relationship field cannot be used in a matching rule.
  • If you enable State and Country picklists for your organization, we recommend usingState/Province Code and Country Code in your matching rules. These fields yield better duplicate detection results than the state and country text fields.
Matching MethodDefines the method for how the fields are compared. We’ve provided an exact matching method that can be used for almost any field, including custom fields. A fuzzy matching method is available for commonly used standard fields. Each matching method is further defined by normalization and match key definitions, matching algorithms, and other criteria.
For more information about matching methods, see Matching Methods Used with Matching Rules.
Match Blank FieldsSpecifies how blank fields affect whether the 2 fields being compared are considered matches. If you select the Match Blank Fields checkbox for any field, and that field is blank in bothrecords being compared, the fields are considered matches. If, however, you select the Match Blank Fields checkbox for any field, and that field is blank in only one of the records being compared, the fields are not considered matches.
If you don’t select the Match Blank Fields checkbox for any field, and that field is blank inboth records being compared, the fields are not considered matches.
Match Key
A formula that allows the matching rule to quickly return a list of possible duplicates. Once a matching rule is activated, match keys are used to generate match key values for all records. When a matching rule runs, it compares the match key values of the saved record with existing records. If the saved record has the same match key value as an existing record, it’s a potential duplicate and evaluated further. If the saved record has a unique match key value, it’s not considered a duplicate. This process improves the speed and performance of duplicate detection.
For more information about match keys, including examples, see Match Keys Used with Matching Rules.
check icon indicating true
Matching Algorithm
Defines the logic that determines whether 2 fields match. For the Exact matching method, the Exact matching algorithm is automatically used. For the Fuzzy matching method, various fuzzy matching algorithms can be used. Each matching algorithm used is automatically given a match score based on how closely it’s able to match the two fields. For example, if you select Exact matching and the two fields match, the match score is 100. If the 2 fields don’t match, the match score is 0.
For more information about matching algorithms, see Matching Algorithms Used with Matching Methods.
check icon indicating true
Scoring MethodDetermines how the matching algorithms’ match scores are calculated to come up with one match score for the field.  Each matching algorithm used is automatically given a match score based on how closely it’s able to match the two fields. Scoring method is used only by the standard matching rules.
Average: Uses the average match score.
Maximum: Uses the highest match score.
Minimum: Uses the lowest match score.
Weighted Average Uses the weight of each matching method to determine the average match score.
check icon indicating true
ThresholdDetermines the minimum match score needed for the field to be considered a match. The field is automatically given a match score based on how closely it matches the same field in an existing record.check icon indicating true


What Are Duplicate Rules?

Your duplicate rules work together with your matching rules to prevent users from creating duplicate records. 

matching rule determines whether the record a user is creating or updating is similar enough to other records to be considered a duplicate, whereas a duplicate rule tells Salesforce what action to take when duplicates are identified. 

For example, a duplicate rule can block users from saving records that have been identified as possible duplicates, or simply alert users that they may be creating a duplicate, but allow them to save the record anyway. 
Each duplicate rule requires at least one matching rule to identify which existing records are possible duplicates.
You can configure your duplicate rule to do something when a record is created and edited. However, the rule only runs for edited records if the fields being edited are included in the associated matching rule.
Duplicate Record Sets:
Quickly see a list of duplicate records, grouped into duplicate sets, by clicking the Duplicate Record Sets tab. To do so, your organization needs to use the report action with its duplicate rules. When a user saves a record that’s identified as a duplicate by a duplicate rule with the report action: • The saved record and all its duplicates, up to 100, will be assigned to a new or existing duplicate record set. • The saved record and each of its duplicates will be listed as a duplicate record item within the duplicate record set. • If the duplicate rule is configured to find duplicates across objects, all cross-object duplicates will be listed as duplicate record items within the duplicate record set. Duplicate record sets and duplicate record items can be used to do the following. • Create custom report types • Create custom fields • Write validation rules, triggers, and workflow rules • Modify the fields that can appear on the respective page layouts 
Duplicate Error Logs EDITIONS Available in: 
 If your organization uses Data.com Duplicate Management, you can view any system errors that prevent the duplicate rules or matching rules from running successfully. From Setup, enter Duplicate Error Logs in the Quick Find box, then select Duplicate Error Logs. There, you can see which, if any, errors occurred. Error logs are deleted after 90 days. 
Example: 
Here are some scenarios that could produce an error on the log.
 • The match engine used for fuzzy matching is temporarily unavailable. Therefore, any matching rules that include fuzzy matching methods will not run. 
• The Report action on duplicate rules fails because the system is unable to create a duplicate record set.
Important Headings:
  1. Matching Methods Used with Matching Rules
  2. Matching Algorithms Used with Matching Methods
  3. Match Keys Used with Matching Rules
  4. How Match Keys and Match Key Values Are Created
  5. Match Key Notation
  6. Pre-Defined Match Keys for Standard Matching Rules
  7. Normalization Criteria for Matching Rule Match Keys 
Why am I getting an error saying my matching rule uses too many OR operators within groupings? 
A matching rule has a limit of 10 fields that are arranged into an equation. When a matching rule is saved, we rewrite the equation into a standardized format that translates the OR statements to AND statements. The standardized format has a limit of 10 rows.
 Example: If your matching rule includes the following equation...
 (Field 1 OR Field 2) AND 
(Field 3 OR Field 4) AND 
(Field 5 OR Field 6) AND 
(Field 7 OR Field 8) ...
it would be rewritten as
 (Field 1 AND Field 3 AND Field 5 Field AND 7) OR 
(Field 1 AND Field 3 AND Field 5 AND Field 8) OR 
(Field 1 AND Field 3 AND Field 6 AND Field 7) OR 
(Field 1 AND Field 3 AND Field 6 AND Field 8) OR 
(Field 1 AND Field 4 AND Field 5 AND Field 7) OR 
(Field 1 AND Field 4 AND Field 5 AND Field 8) OR 
(Field 1 AND Field 4 AND Field 6 AND Field 7) OR 
(Field 1 AND Field 4 AND Field 6 AND Field 8) OR 
(Field 2 AND Field 3 AND Field 5 AND Field 7) OR 
(Field 2 AND Field 3 AND Field 5 AND Field 8) OR 
(Field 2 AND Field 3 AND Field 6 AND Field 7) OR 
(Field 2 AND Field 3 AND Field 6 AND Field 8)OR 
(Field 2 AND Field 4 AND Field 5 AND Field 7) OR 
(Field 2 AND Field 4 AND Field 5 AND Field 8) OR 
(Field 2 AND Field 4 AND Field 6 AND Field 7) OR
(Field 2 AND Field 4 AND Field 6 AND Field 8) 

Although this matching rule is within the field limit, it exceeds the row limit of 10 when written in the standardized format, and therefore can’t be saved. You need to refine the matching rule so it uses fewer OR operators within groupings.

How does duplicate prevention work with Data.com Prospector and Data.com Clean? 
Adding Records with Data.com Prospector 
It depends on what your organization’s Data.com duplicate preferences are. If your organization does not allow duplicate records to be added to Salesforce from Data.com, then Data.com will block duplicate records from being added to Salesforce and the duplicate rule won’t need to run. The user trying to add records from Data.com will receive an error log detailing which records couldn’t be added because they are duplicates. If your organization allows duplicate records to be added to Salesforce from Data.com, then the duplicate rules will run. The duplicate rule will determine if the duplicate record is allowed or blocked. Records that are blocked by the duplicate rule will appear in the error log.  

Updating Records with Data.com Clean :
It depends on what your organization’s duplicate rules are. If your duplicate rule is set to block duplicates on edit, then a record can’t be cleaned if cleaning creates a duplicate. For Clean jobs, if your duplicate rule is set to block or alert, then a record can’t be cleaned if the cleaning creates a duplicate. An entity error appears in the Clean Jobs History table for any record that can’t be cleaned during a job. If your duplicate rule is set to allow duplicates on edit, then a record can be cleaned even if it creates a duplicate. In addition, no alert displays when manually cleaning records even if your duplicate rule is set to alert. 


No comments: