The AutoMerge Management Application is an xRM model-driven application built on the same Dynamics platform as your CRM. The Management App is where you define your duplicate matching rules. Using those rules, you can submit requests to analyze for and tag duplicates in your CRM.
Access to the Management Application is for paid AutoMerge subscribers only. Contact us if you are interested in starting a trial.
Once you receive an invitation to connect to the AutoMerge Management Application, go to https://automerge.crm4.dynamics.com. Enter your usual Office 365 username and your password on the subsequent domain specific page.
Once you log in to the AutoMerge Management Application, you will see your customer record.
Click your customer record to open your organization’s main profile. Your organization’s main profile should include your organization name, contact email address, mobile number for notifications, and a default CRM connection to use for new requests.
The CRM connection form is where you give the AutoMerge Service access to your CRM system. Here, you can define multiple connections to your Sandbox organizations and one connection to your Production organization.
On the CRM connection form, only the “Name” and “Purpose” fields are editable. Most fields are automatically edited via the “VERIFY URL,” a feature which gathers credentials securely and verifies that they work.
To edit an already-verified connection or to remove credentials, check the “Clear Credentials” checkbox and then click “Save.” Click the “VERIFY URL” to edit the connection.
With the exception of the password, all connection information is stored directly on the record. The password itself is encrypted and stored securely elsewhere.
To create a new CRM Connection, simply go back to your Customer profile record and click the “+ New CRM Connections” button.
If you have trouble connecting your CRM, it might be due to Multi-Factor Authentication.
When AutoMerge service does the analysis for duplicates, it follows a set of rules that are kept together in a single configuration record.
The five parts of a configuration are:
With the exception of the Custom FetchXML statement, all of the above is required for a successful analysis. These configurations are also fully customizable.
To better understand the five configurations from above, we will take you through the “Contact-XXXXXXXX” record.
In this record, the GENERAL tab includes:
NOTE: In addition to the FetchXML Filter above, the CRM user that is configured in the CRM connection may be limited by its security roles and hence may further filter which records are analyzed during requests.
The MATCHING tab has a list of rules used to find duplicates during analysis. Any number of rules can be defined, but ultimately each duplicate record can only belong to a single match set. The rules are applied in order according to the precedence number in the second column. The “Match Type Name” in the third column is how the duplicate sets are categorized in your CRM after tagging.
The RANKING tab has a list of rules used to sort the resulting members of a duplicate set. This is important because the record that “wins” (where Rank is #1) the AutoMerge operation in your CRM will remain. All the other records of the set (where Rank is >1) will be deactivated.
Automatic Field-Preservation: During an AutoMerge of a duplicate set, any un-populated fields in the winner record will be filled in by values found in the losing records. This is simple “Non-NULL replaces a NULL” logic. More complex decision-based field preservation logic is possible using workflow rules.
In the Customer-XXXXXXXX record, we created a Ranking Rule in the “customertypecode” field to ensure contacts of particular type (i.e. “Customer”) are ranked better than other types (i.e. “Vendor.”) In other words, a customer contact will always win an AutoMerge over a vendor contact. If the first rule doesn’t differentiate all duplicates in every set, the second rule will apply and give preference to the most recently modified contact.
TIP: Matching, Ranking, and Precision rules can also be based on fields from N:1 related records such as a contact’s parent account. For example, you might consider ranking duplicate contacts based on their parent account’s owning user.
The PRECISION tab shows the matching rules (“schemanames”) that are weighted together to give the duplicate sets a number from 0-100 based on how closely matched the members of each duplicate set are.