- \n
- Paribus 365™ Data Cleansing<\/li>\n
- Microsoft Dynamics CRM<\/li>\n
- Infor CRM (Saleslogix)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\nNote: This article assumes the reader has read the included Paribus 365™ Data Cleansing documentation and understands the basic concepts of the building blocks of the Paribus 365™ Data Cleansing configuration, including Data Providers, Data Sets, Match Conditions, Match Sets, and Match Sessions. In addition, you should be familiar with how to run a Paribus 365 Cleansing Session for your CRM system.<\/p>\nIntroduction<\/h2>\n
In a previous article – Gaining Efficiencies with Paribus 365 Data Cleansing \u2013 Filters<\/a>, we covered many of the basic steps to setting up logical Match Sessions and how to create Filters that will make sense for your particular needs. This article is a continuation of the theme of maximizing efficiencies through an informed configuration of your Paribus system.<\/p>\n
Data Set Information Columns<\/h2>\n
During the Match Session process, when Paribus 365 finds matching records, it will collect some information about those records. In the Data Set definition, this information is called the Information Columns:<\/p>\n
![\"Paribus](\"\/help\/wp-content\/uploads\/2017\/01\/DR1.png\")
<\/a><\/p>\nThe information requested here will show up in the Paribus 365 Review screen in blue text for the Reviewer to use to answer the two questions:<\/p>\n
Q1) Are the members of this group of matches actually duplicates we would like to process?<\/p>\n
Q2) If we agree that the records should be merged, which record should be the surviving record?<\/p>\n
![\"Paribus](\"\/help\/wp-content\/uploads\/2017\/01\/DR2-1024x561.png\")
<\/a><\/p>\nWith the goal of spending the least amount of time in the Review process as possible, the key is to select just the right information for Paribus to gather for the review to allow the Reviewer to make quick, informed decisions. If you\u2019ve constructed some initial Match Sessions, with very high Match Thresholds, you should have been able to clean up many of the obvious matches with very little or no review. However, as you lower the Match Thresholds to allow for more variations, in an effort to catch the less obvious matches, your Reviewer will now be evaluating each Match Group to make the decisions on which Groups to approve and (potentially) which Member should be the Primary (surviving) record.<\/p>\n
So, what should you be including in the Information Columns? Some of the most commonly used information is already included in the pre-set Definitions that you likely imported into your Control Database. Things like:<\/p>\n
For Account Matches<\/p>\n
- \n
- Full Primary Address<\/li>\n
- Main Phone Number<\/li>\n
- Web Address<\/li>\n
- Type<\/li>\n
- Date Created<\/li>\n
- How many History records<\/li>\n
- Date of the most recent History record<\/li>\n<\/ul>\n
For Contact Matches<\/p>\n
- \n
- The Contact\u2019s Account Name<\/li>\n
- Physical Address<\/li>\n
- Email Address<\/li>\n
- Work Phone<\/li>\n
- Mobile Phone<\/li>\n<\/ul>\n
There are more data values included in the pre-built Definitions, but the above are good examples of what almost everyone would include. Having these items in the review screen for each Match Group goes a long way to help the Reviewer determine whether or not the Members of the Group are actually matches.<\/p>\n
When performing an Account Match, the common tactic is to match on things like the Account Name and Addresses, but when you start allowing for more \u2018fuzziness\u2019 or variations in the matching criteria, you might be catching companies that are similar in name and address, but without being able to see things like their phone number or Web address, you wouldn\u2019t be able to confirm with confidence that they truly are matches.<\/p>\n
Similarly, with Contact Matches, the common setup is to look for Contacts with similar Names who are at the same Account, but with family businesses or larger companies, you might have more than one person with the same name \u2013 or Jr. and Sr. from the same family.<\/p>\n
Providing more information (not too much more!) in the review can help your Reviewer make the right decision, and placing just the right information in just the right order can help them make the decision faster!<\/p>\n
Some suggestions that might help:<\/p>\n
For Account Matches<\/p>\n
- \n
- Account Number from your Accounting System (maybe you need to have duplicates, so different Account Numbers would tell you NOT to merge)<\/li>\n
- Status or some custom designation (an Active Account might have better information than an Inactive Account)<\/li>\n
- The Account Manager\u2019s Name (often used to determine the Primary when there are 2 different Account Managers on a duplicate \u2013 or inform you about who to ask regarding that Account)<\/li>\n
- The number of Open Opportunities (although any Opportunities from duplicates will be moved to the Primary in the merge, if you\u2019re actively working on a sale with an Account, that Account might have better core information and therefore a better Primary record)<\/li>\n
- The Import Source (this may indicate the quality of the core data)<\/li>\n<\/ul>\n
For Contact Matches<\/p>\n
- \n
- Many of the same items as above<\/li>\n
- Contact Title (you may wish to choose the Primary based on this)<\/li>\n
- The number of Activities (if you have scheduled Activities on one Contact and not the other, that might indicate that the core data on the active Contact is better)<\/li>\n
- Last History date (this may indicate that you\u2019ve had interaction with one Contact more recently than another and help make the Primary choice easier)<\/li>\n<\/ul>\n
All of these are simply suggestions. We\u2019ve found that across a wide range of clients over the years that there isn\u2019t any one \u201cRight\u201d answer as to what to include. And, as important as it is for you to include the relevant information to help your Reviewer, it\u2019s equally important to NOT include irrelevant information, as that just adds \u201cnoise\u201d to distract your Reviewer from what they need to see to make their decision(s).<\/p>\n
Syntax and Layout<\/h2>\n
What you\u2019re entering in the Information Columns fields are the selected columns (attributes) of data you would like Paribus to gather and the labels that you would like to be displayed. If you don\u2019t specify a specific label, Paribus will display the name of the column from the table.<\/p>\n
What you\u2019re entering will be collected up into a SQL statement that will then store the information into the Paribus Control database as part of the Results of your Match Session.<\/p>\n
Your selection can be as simple as the column name. For instance, if you wanted to display the Account\u2019s Website value, the name for that column in the Account entity is WebSiteURL (in Microsoft Dynamics CRM, for example). You could enter it in as Account.WebSiteURL<\/strong>, but then the value in the review screen would carry the label WebSiteURL. If you entered it in as Account.WebSiteURL as \u2018Website\u2019<\/strong>, then the label would be \u201cWebsite\u201d, as it is shown in the screenshot above.<\/p>\n
Each item you select needs to be separated by a comma and each element will appear one-per-line in blue text in the review screen. Items that show in red in the review are values Paribus matched on based on your settings.<\/p>\n
Using more complex subqueries (counts, etc.) and correlated subqueries (complex counts, most recent records, etc.), you can get quite a selection of information for your Reviewer. There are some examples of these included in the pre-set Definitions, and here are some examples from both Microsoft Dynamics CRM and Saleslogix\/Infor CRM:<\/p>\n
Saleslogix\/Infor CRM<\/strong>
\nShow the name of the User who wrote the most recent History record for an Account
\n(SELECT USERNAME FROM USERINFO WHERE USERID = (SELECT TOP 1 COMPLETEDUSER FROM HISTORY WHERE HISTORY.ACCOUNTID = ACCOUNT.ACCOUNTID ORDER BY COMPLETEDDATE DESC)) AS ‘Last History User’<\/p>\nShow the number of user-created (not system generated) History records for an Account
\n(SELECT COUNT (HISTORYID) FROM HISTORY WHERE HISTORY.ACCOUNTID = ACCOUNT.ACCOUNTID AND HISTORY.TYPE <> ‘262156’) As ‘Count of History Records’<\/p>\nMicrosoft Dynamics 365 CRM<\/strong>
\nShow the number of Contacts for an Account
\n(SELECT count (ContactID) from dbo.Contact where dbo.Account.AccountID=dbo.Contact.ParentCustomerID) as ‘Number of Contacts’<\/p>\nShow the Date of the most recent Scheduled Activity for a Contact
\n(SELECT TOP 1 ScheduledEnd FROM dbo.ActivityParty WHERE dbo.Contact.ContactID=dbo.ActivityParty.PartyID ORDER BY ScheduledEnd DESC) As ‘Scheduled Latest Activity’<\/p>\nWhat appears in the review screen is entirely up to you. Take some time during the setup process to think this through. Talk to your business users who understand the use of your data and who will be making these decisions or who will be impacted by your decisions.<\/p>\n
What information would aid your Reviewer to make the best choices as quickly as possible without having to look at the records within your CRM system itself? Remember, the more attention to details like this during the creation of your Paribus settings, the better your results will be and the faster you\u2019ll get through your cleansing project and on your way to cleaner data.<\/p>\n
<\/p>\n