5 Quick Tips to Merge Accounts in Salesforce Lightning
10 min
At some point, almost every organization realizes a terrible truth . . . they have a massive number of duplicate records. Duplicates create a myriad of issues for users. From inaccurate reporting to double-work on the same account to different reps working the same lead, this challenge can be very damaging to sales operations as well as users’ confidence in their system. By the time leadership realizes there is a duplicate problem, it’s typically so widespread that it leaves users and managers exasperated.
Time to bring in the Salesforce expert to save the day.
De-duping records can potentially be an arduous process. This article’s aims to give you useful tips at cleaning up that data disaster, and successfully merging the records down to one useful actionable account.
1. An Ounce of Prevention . . .
. . . is worth a pound of cure. Before beginning the process of cleaning up your data, take some time to ensure that new duplicates aren’t created moving forward. As with any updates to Salesforce, start by understanding the business requirements, and don’t be afraid to make some suggestions to help the company out.
Quality data is a requisite in the modern age of advanced analytics. Multiple records with the same name create a variety of problems first and foremost reporting data. Salesforce is a powerful tool when utilized correctly, and fortunately the combination of Matching and Duplicate Rules help keep the data clean.
Talk to key department leaders to understand the proper naming convention for Accounts, Leads, Contacts, Opportunities, and more. Take time to understand where leads come from, and how they are named. For example, do leads come from an online form submission? A good approach may be to make email unique to prevent the same person from registering twice. Are leads purchased from a list provider? Prevent duplication upon import to avert a “junk-in junk-out” scenario. Maybe users are creating leads. As a training point, managers should instruct end users on proper naming conventions and utilize the Matching/Duplication Rules to require the convention.
Guidance, input, and buy-in from leaders and managers will ensure future duplicates are prevented by establishing rules and processes on the business side and enforcing them in Salesforce.
2. Matching Rules
Matching and Duplicate Rules work together to help prevent duplicates as well as dealing with existing ones.
Matching rules identify the situation when two (or more) records are identified as a dupe. Duplicate Rules define what to do once the match has been determined.
Matching Rules can be set up on Accounts, Contacts and Leads, and you can set up to five rules for each object. Why would anyone utilize multiple rules for the same object? This gives us the ability to set up different Duplicate Rules for different situations. For example, we may have accounts that are similar while other account pairs are identical. The similar pairs of accounts might have slightly different names or differing addresses to go with the same account name. Identical scenarios have the same Account name, address and phone number.
To identify fields that are close, but not exactly the same, we can use Fuzzy Matching. This eliminates filler words like “the”, slight spelling differences (Theater vs Theatre), abbreviations (Street vs St.), and general misspellings that are only a few letters off (Brett Favre vs Brett Farve . . . wait which one is correct?).
Set the Matching Rule based on the Account, Contact or Lead object. Then determine which fields you want to use to find the matches. Choose between Exact of Fuzzy matching method and decide how you want to handle blanks. Tip: lead Match Blank Fields unchecked for most scenarios. The matching rules are used to find duplicates and checking this box will just exclude potential matches from the search.
3. Duplicate Rules and Duplicate Jobs
Now that we have found them, we need to specify how to handle each situation through Duplicate Rules. After naming the rule and determining how to handle security, we quickly get into the heart of the matter. For both record creation and edit, we have the choice of “Allow” or “Block”. Blocking prevents the user from saving a record the meets the Matching Rule – it’s like a validation rule. The Alert Text tells the user what is happening. If we choose “Allow”, we can opt to Alert the User that they are in the process of creating a duplicate (so they can choose to dedupe on their own). We can also set up Reporting on records that are saved and meeting the Matching + Duplicate Rules.
The Matching Rule we created in the previous step is applied here. There is also an option to compare Accounts with other objects. It is not inconceivable that Account information could be erroneously entered as a Contact or vice versa.
In higher level editions like Performance and Unlimited, there is a powerful tool called Duplicate Jobs. While Duplicate Rules are excellent to prevent future dupes, the Jobs function to track down duplicates that already exist in the org. These once again leverage Matching Rules along with customizable criteria. When we run the Duplicate Job, it creates Duplicate Record Sets (groups of two or more records that meet the rule and criteria). We then have the option to run through the Record Sets to “Compare and Merge.”
4. Merging . . . Side by Side
After understanding business rules, determining how we match records, and setting up rules for duplicates, it is finally time to merge. Merging can be done organically in Salesforce or by utilizing a third-party app. We’ll compare the two options, but first let’s understand what we can do with the native functionality.
Salesforce has a pretty user-friendly merge function, with a few limitations. We have the ability to compare and merge up to three records together. When comparing two or three duplicate accounts, we can determine which account is the “master” and pull in fields from any of the records in the comparison. The “master” is important because the record ID, sharing rules, and other information (such as territories, divisions, teams, and parent accounts) will default to the master record (also known as the “primary” record).
Once the records have merged, related items from both or all three records will now be attributed to the new merged account. This means that contacts, cases, files, and even chatter will be carried over to this updated record. You may notice that duplicate accounts may have a similar contact related to each of the accounts. We can identify these duplicate contacts and dedupe those as well. Just make sure to run dedupe processes on the accounts first, which will make contacts easier to find. After the merge, the remaining account stays put while the other one or two is moved to the trash.
When more than three duplicates of a single account exist, deduping can still be performed through a few iterations. For example, say that there are 5 copies of Acme Inc. Salesforce will alert us that duplicates exist for the account and will provide a link to view duplicates. We can select three of the five to start and merge them down to one. This will still leave three duplicates (two of the original plus the one account we just merged into). Going back to one of the Acme Inc accounts will again prompt us to view duplicates and we can perform merging one more time.
5. Third-Party Apps
As you can imagine, this iterative process can be cumbersome. Imagine if you have 17 duplicates of the same record (don’t laugh! It happens). The good news is that there are a plethora of third-party apps available with advanced merging capabilities. We won’t go through a ranking or comparison in this article, mostly because they are generally very similar. However, let’s cover a few important things to know about them.
- First
- The third party apps still utilize the same concept of a primary/master record within the merge. This is important for determining how security will work for the record after the merge. For organizations utilizing territory sharing, the primary record’s territory assignment will still take precedent. Sharing rules from the primary will take effect, as will account team assignment and other partner relationships. The default parent account stays with the primary/master – although in some situations we have the ability to designate a different parent.
- Next
- Outside applications offer features such as exclusion. In the Acme scenario described above, we may have the five records lined up to compare, and realize that only four of the five meet the business definition of a duplicate. We can omit the one record, and pull in fields from the other four to merge into a new account. We will retain two Acme records in this scenario: the one record that wasn’t a duplicate and the merged record.
- Another feature of third party apps is the manual update function. Let’s say that two duplicate records have the following street addresses:
- Nw 4th St.
- NW 4th ST.
Neither of those are very satisfying. Some apps allow us to choose to edit the field right in the app.
For example, capitalizing the W in the first address line and selecting that as the address to be used in the merged account. This is a handy feature that saves the step of going back to the record and saving as a separate action before or after the merge.
- The next benefit should be used with caution: Mass Merge.
- After setting matching and duplicate rules, third party apps often allow us to apply a set of change rules to a large quantity of records. With great power comes great responsibility, though. Make sure your rules are rock solid before applying merging rules to a large quantity of data. It can be extremely difficult to unwind. Consider an org back-up before going down this road to be safe.
Last, as we forge deeper into the world of analytics, machine learning, and AI, some third party apps and “Big Data'' companies offer advanced methods of identifying, preventing, and merging duplicate records. The technology is pretty slick, although certainly not the least expensive up-front cost. In fairness, sales reps would undoubtedly assert that in the long run the advanced version actually saves money.
