Configuring Match Rules – Deep Dive

Deep Dive: Configuring Match Rules in the AutoMerge Management App

The match rules within your Matching/Ranking Configuration record reference a particular entity (Lead/Account/Contact) and determine how the analysis engine finds duplicates in your CRM. 

The default set of Match Rules created under each of your Matching/Ranking Configurations are suitable for typical CRM systems where the usual built-in fields from the Lead/Account/Contact entities are used. Fields containing data that uniquely identifies a person or a business such as firstname, lastname, company name, telephone, email, street address, etc… are key to setting up proper rules for your dataset.

Let’s go over how to view/edit, disable/enable the default match rules, and create new rules.

Log in to the AutoMerge Management App and open your Customer record. Switch over to the “Matching/Ranking” tab to see all your configs records. Click open the Matching/Ranking Configuration for Contacts: 

The five parts of a Matching/Ranking Configuration are:

  1. The Entity Definition of the entity under analysis. (i.e. Contact). This contains a small list of field definitions our service needs to do its work. By default it only uses name/address/phone/email type fields for matching and ranking purposes. If you will be customizing the matching or ranking (or precision) rules to use other built-in or custom fields, you FIRST need to add them to the Entity Definition. => 
    Learn how to edit your Entity Definition in this other article: Entity Definition Deep-Dive

  2. Custom FetchXML statement that determines which records should be analyzed. This can be generated from CRM’s Advanced Find tool. If this is left blank, all active records of the Entity are used.

  3. A set of Matching Rules. These are used in a specific order to find duplicates in your CRM.

  4. A set of Ranking Rules. These are used to sort the members of the duplicate sets found in #3.

  5. A set of Precision Rules that feed an algorithm that gives the resulting duplicate sets a number from 0-100 based on how closely matched various fields are across the members of each duplicate set.

We are focusing on the Matching Rules in this article:

Active Matching Rules are applied to the filtered dataset in order of the Processing Sequence. When a match (2 or more duplicates) is found, those records are tagged with the Match Type Name

Simply Deactivate a Match Rule you don’t want to apply during the next Analysis.

The Summary gives you a concise one-line description of the rule. A match rule consists of an optional X-Field “Crossfield” and up to 10 regular Match-Fields each with their specific settings.

Let’s jump into a Match Rule to see how it works:

A match rule consists of

  • Match Type Name which is what the matches are labelled in your CRM during an Analysis>Tagging request.
  • Processing Order which determines what sequence this rule should be applied vis-a-vis other rules. Lower numbers are processed first.
  • Summary of the rule that is auto-generated for you.
    • X = crossfield. There can only be one of these.
    • *  => fuzzy matching is enabled on that field
    • 0 => that field can match on NULLs (empty values)
  • an optional X-field Type which defines what type of fuzzy-matching should be used for the X-Field Schemanames.
    • if a rule doesn’t need X-Fields, simply set this field to “N/A”
  • The corresponding X-Field Schemanames which is a comma-separated list of fields to search across for duplicates.
  • And lastly a list of up to 10 match fields. But usually 1 or 2 will suffice.

For the above FIRST-LAST-PHONE example, a match is successful when:

  • Any of the X-fields of 1 record matches any of the X-fields of 1 or more other records.


  • All of the active match fields in the list also match across those same records
    • Inactive match fields are ignored. And deactivating a match field is less permanent than deleting it all together.

When you submit an Analysis>Tag Request against the above Matching/Ranking Configuration a textual snapshot of the Config is captured for historical reference. Because you can edit a Configuration over time, this snapshot gives you a reference point of what the matching/ranking rules looked like at submit time.

Happy AutoMerging!