Garbage in, garbage out.
Duplicates are terrible for a CRM. One of your primary objectives as an Administrator of a Salesforce Org is to protect it from duplicate records. If you're coming from Part 1 of this series, you've cleaned your org of existing duplicates and it's a pristine source of truth for your users. If you want to keep it that way, you need to create some counter measures to fight against any new duplicates getting added.
First and foremost, before you ever touch Salesforce Setup, you need to decide on the logic that will determine that a record is a duplicate. For some objects, this is easy. For example, in the majority of cases, Contacts and Leads should have unique email addresses. The logic for lead/contact duplicates can be as simple as not allowing the same email address on multiple records(as long as email is a required field).
Other objects won't be so simple. Accounts, Opportunities, and custom objects can be much more difficult to keep duplicate free. End users and stakeholders are important in this process, because Salesforce should ultimately be structured based on how your company organizes clients.
A key place to start when writing duplicate logic is to pay close attention when you or your users encounter duplicates when you're not looking for them. When you find a duplicate, write down which fields and data sent up red flags. Was it the name of the records? In the case of Accounts, was it a combination of fields like Type, Industry, or other picklist fields? Were there any custom fields that had suspiciously similar information?
You can also flip this line of thinking and ask yourself, "What fields guarantee that this record is different than another record?" Use these questions and meetings with stakeholders to get a running list of potential duplicate logic, and slowly refine it until you have your final criteria.
Matching vs Duplicate Rules
When you're ready to implement your duplicate logic, you'll be creating a combination of 'Duplicate' rules and 'Matching' rules. Matching rules define what constitutes a duplicate -- this is where you'll input your list of criteria discussed above. Duplicate rules control what happens when a duplicate is encountered. You can choose whether a user is blocked from creating duplicate records, or just warned that they're likely creating a dupe. You can also write the warning message that is shown.
First, create your matching rules. If you're only working with standard objects, Salesforce has a fairly robust set of matching rules that can be used for Accounts, Contacts, and Leads. You can read about them here.
Next, create duplicate rules and match them up with the corresponding matching rules. Set them to active, and enjoy the wave of stress relief from having an org protected from duplicates!
It's a good idea to at least check the 'Report' option on duplicate rules. If a record is created that is flagged as a duplicate by your matching rules, it will be recorded in a Duplicate Set record that can be reported on later. If you don't block users from creating duplicates, you should at the very least record when duplicates occur.
Block, Report, Audit
It's up to you to come up with a duplicate prevention strategy that works for your organization. However, it's a good idea to follow the pattern of block, report, audit. Simply put, this means to block as many duplicates as you can. Objects with simple, straightforward duplicate logic (like requiring a unique email address) are good candidates for this. For objects that are more complicated, check the 'Report' box on all of the object's duplicate rules to ensure that all potential duplicates are tracked. Then, set up a schedule to audit the duplicate reports and clean up any legitimate dupes.
Depending on the complexity of the duplicate rules, you can also block certain types of duplicates but only warn/report on others. This can keep the manual review of duplicates limited to the complicated cases, and ensure the simpler cases are blocked.
Any investment you put into duplicate prevention will pay itself back in dividends. Good luck, and happy admin-ing!
-Loren