Duplicate Contact Scenarios Explained

Article ID: 519

Last updated: 03 Nov, 2022

Customers have asked why duplicate contacts appear in user's email address books after Riva sync has been enabled. This article explains nine of the most common scenarios involving duplicate contacts and provides best practices to avoid, reduce, and correct issues with duplicate contacts.

Duplicate Contact Scenarios

The following scenarios can generate duplicate contacts:

Scenario 1 - Pre-existing contacts in email address books
Scenario 2 - Pre-existing duplicate contacts in the CRM
Scenario 3 - CRM or Riva security model prevents user visibility to all contacts
Scenario 4 - Users are using CRM plug-ins for Outlook and Riva at the same time
Scenario 5 - User is assigned to two different Riva sync policies at the same time
Scenario 6 - User is assigned to Riva sync policies on different Riva servers
Scenario 7 - CRM has a contact and a lead for the same contact
Scenario 8 - User is moved between sync policies improperly
Scenario 9 - SmartConvert converts an email and creates duplicate contacts

Scenario 1 - Pre-Existing Contacts in Email Address Books

If a user has pre-existing contacts in their email address book that match contacts in the CRM, when Riva performs an initial sync, Riva creates a copy of the CRM contact in the target user's email address book. When composing an email or viewing all contacts alphabetically in a list view, duplicate contacts will be discovered.

Remember that Riva does not always sync all contacts from the CRM to the target user's email address book. The Riva sync policy includes date/time, security, and organic filters that can prevent some of the CRM contacts from being synced to the target user.

Sometimes duplicates are created (pre-existing contact and Riva-synced contact) and sometimes only pre-existing contacts exist in the target user's email address book. Removing all pre-existing contacts from the user's email address book is not a recommended practice unless all CRM contacts will be synced to the target user.

Best practice tips

After the Riva sync cycle, list all contacts in an alphabetical view. Riva-synced contacts will be categorized with the Riva category name specified in the Riva sync policy. Users can choose to:

remove pre-existing contacts from their email address books
move pre-existing contacts to a contact list that is not automatically searched for auto-complete when composing emails and calendar appointments.

Scenario 2 - Pre-Existing Duplicate Contacts in the CRM

Most CRM systems permit the creation of duplicate contacts. If duplicate contacts for the same individual exist in the CRM, Riva syncs existing duplicate contacts to the target user's email address book.

Best practice tips

Before Riva's initial sync, an effort should be made to clear (remove or merge) duplicate contacts in the CRM. This greatly reduces unnecessary data sync and reduces the chance for the apparition of duplicate contacts in user email address books. If duplicate contacts are required, ensure that contacts are assigned to (owned by) the correct individual in the CRM, and consider using "Filter by: Must be Owner" in the sync policy. (For more information, see Configure a sync policy - Address books) and organic contact filters. For SugarCRM systems, Riva also supports Sync to Outlook configured in the Riva connection to the SugarCRM system.

After the Riva sync cycle, list all contacts in an alphabetical view. Riva-synced contacts will be categorized with the Riva category name specified in the Riva sync policy. If users spot duplicate contacts synced from the CRM by Riva, recommended corrective action includes:

Remove or merge duplicate contacts in the CRM. Any changes to contact objects in the CRM will be synced down to the target user email accounts. If a contact is removed from the CRM, it will be removed from the user's email address book. If contacts are merged, Riva will make the necessary adjustments in the user's email address book.
If duplicate contacts are required, follow the same procedures as before Riva's initial sync.

Do not remove duplicate CRM contacts from the Outlook address book. This may result in sync errors. Make contact adjustments in the CRM.

Scenario 3 - Riva Syncs a New Contact to the CRM and Creates a Duplicate Contact

The user creates a new contact in their email client address book, which is then categorized to sync to the CRM. Riva syncs the new contact to the CRM (without checking for a match in the CRM) and potentially creates a duplicate contact assigned to (owned by) the creating user. On the next sync cycle, Riva syncs that new contact (even if it is a "duplicate" contact) to all the other target users specified in Riva sync policies.

In those environments where access to contacts in the CRM is controlled by using Teams, Groups, or Roles, it is possible for the user to not "see" an existing contact in the CRM. If the user cannot see a contact, Riva cannot see that contact for that target user. Riva impersonates a CRM user and uses the effective access permissions assigned to the user in the CRM. Consider these two common examples:

The CRM limits access to contacts. It is possible for a contact to exist in the CRM and not to sync to a target user (for example, Bob). If that user then creates a contact in Outlook and Riva syncs that as a new contact to the CRM, Riva creates that as a new contact assigned to the target user (Bob). If the CRM prevents the occurrence of duplicate contacts, then Riva fails to create that contact. Now there are two identical/similar contacts in the CRM.
The Riva Sync Policy uses "Filter by Ownership" for contacts. In this example, even though the target user (for example, Bob) can see the contact in the CRM, Riva syncs based only on contact ownership. If a different user owned a contact (for example, Ian Sample), Riva would not sync a copy of the contact to Bob's Exchange account (Outlook address book). Bob could create a new contact in Outlook and Riva could sync that contact to the CRM as a new contact owned by Bob. Now there are two identical/similar contacts in the CRM.

Possible best practice options

If this is a consistent issue, consider configuring the Address Book settings in the sync policy to.

perform uni-direction, read-only sync of contacts from the CRM to the email system. This prevents new Outlook contacts from syncing back into the CRM.
select "Require Category", which forces the user to manually set the Riva category when creating the contact in the email address book. This reduces but does not eliminate the chance for duplicate contacts.
if available, enforce "prevent duplicate" mechanisms in the CRM.

(For more information, see Configure a sync policy.)

Scenario 4 - Users Are Using CRM Plug-ins for Outlook and Riva at the Same Time

Users are running a CRM Outlook plug-in and are being synced by Riva at the same time. Riva is not aware of any other 3rd party sync product or process that can be creating contacts. If a plug-in normally auto-creates a new contact made in Outlook and Riva normally auto-creates a new contact made in Outlook, then each process will sync the same new contact to the CRM, which then may be resynced as a new contact by the other sync solution back to Outlook. Example:

Bob creates a new contact for Ian Sample in Outlook.
The Outlook plug-in sees the new contact in Outlook and syncs it to the CRM. (Call that "isample-p1".)
Riva sees a new contact in Outlook and syncs it to the CRM. (Call that "isample-r1".)
Riva sees a new contact (isample-p1) in the CRM that it did not create and assumes that a normal user created it. Riva syncs that new contact (isample-p1) back to Outlook.
Now there are duplicate contacts in the CRM and duplicate contacts in Outlook for the same original contact.

Best practice

As a best practice, we recommend that all other 3rd party CRM sync mechanisms, like Outlook plug-ins, be disabled and/or uninstalled for target users being synced by Riva.

Question: Can Riva co-exist with Outlook plug-ins or other CRM sync mechanisms?

Answer: Yes, but it takes careful consideration, planning, and testing. Essentially, ensure that the modules that other CRM sync mechanisms sync between the CRM and the user's email account are not enabled in Riva. For more information, see Preventing duplicates: Working with Outlook plug-ins and Riva.

Scenario 5 - User Is Assigned to Two Different Riva Sync Policies at the Same Time

A target user is assigned to two different Riva sync policies in the same Riva server. Riva treats both user assignments as unique: in effect, you end up syncing the same user twice, which creates a situation similar to Scenario 4.

Best practice

Do not add the same target user to multiple Riva sync policies.
Apply an App.Setting on the Riva server to prevent syncing a user if assigned to two or more sync policies.

Scenario 6 - User Is Assigned to Riva Sync Policies on Different Riva Servers

A user is assigned to a Riva sync policy on two different Riva servers. In effect, the same target user is synced twice, which creates a situation similar to Scenario 4.

Best practices

Scenario 6 occurs most commonly when

A target user is assigned to a sync policy on a Riva On-Premise server and is also configured with a Riva Cloud (www.rivasync.com) account.

Best Practice - If testing both the Riva On-Premise server and Riva Cloud, do not use the same target users for both systems.
A Riva On-Premise server is moved to a new Windows system without properly de-commissioning the original Riva server.

Best Practice - For the correct procedure, see Move Riva to a different Windows system.

Scenario 7 - CRM Has a Contact and a Lead for the Same Contact

Some CRMs support creating contacts for leads. Some CRMs retain leads as leads even after those items are converted into accounts/organizations and contacts. Under those conditions, if the Riva sync policy is configured to sync both contacts and leads, it may appear that there are duplicate contacts created by Riva in the Exchange/Outlook address books.

This is considered a normal circumstance. Since email clients cannot distinguish between a contact or a lead, Riva syncs leads as contacts but assigns them to a different category. In Outlook, if contacts are viewed by category, you can see the difference. In GroupWise, leads and contacts are synced into separate address books.

Best practices

Some recommended best practices include:

For Exchange/Outlook environments, configure the sync policy to set a different category colour for leads.
From a CRM perspective, develop common working practices to remove leads once converted to accounts/organizations and contacts.
(Optional.) If syncing leads becomes too confusing, disable sync of leads into address books.

Scenario 8 - User Is Moved Between Sync Policies Improperly

Users can be removed from one sync policy and added to a different sync policy. Unfortunately, depending on how the gaining sync policy is configured, Riva sync may react differently.

Example 1 - User is moved to a sync policy with the same category names.
Example 2 - User is moved to a sync policy with different category names.
Example 3 - User is moved back to a policy it was previously assigned to.

There are proper methods to move users between sync policies that minimize the creation of duplicate items and preserve data sync between the CRM and the email system. Always follow the recommended procedures to move users between sync policies.

Example 1 - User moved to sync policy with same category names

In this example, a user is removed from Losing Policy and added to Gaining Policy. Both sync policies use identical category names for all modules (for example, address book, calendar, and tasks).

In this situation, when a user is removed from the Losing Policy, Riva retains the transactions for that user against that policy. When the user is added to the Gaining Policy, a new set of transactions records are started against the gaining policy. Riva runs an initial sync against the target user's mailbox. Because Riva discovers items that are already categorized with Riva category names, Riva creates "Lost & Found" folders and moves those pre-categorized items to "Lost & Found". This is done to prevent Riva from syncing duplicate items to the CRM. Riva then syncs a fresh set of contacts, appointments, tasks, opportunities, cases, etc. to the target user's mailbox. The email address book now contains two set of contacts for each Riva-synced CRM contact: the fresh set and the "Lost & Found" set.

Correct Procedures

When moving users to existing policies with the same category names, follow the Move target Exchange users to another sync policy using identical category names procedure to prevent "Lost & Found" duplicate items in email address book.
When moving users to new sync policies that will use the same category names, follow the Move target Exchange users to a duplicate sync policy procedure to prevent "Lost & Found" duplicate items in email address book.

Example 2 - User moved to sync policy with different category names

In this example, a user is removed from Losing Policy and added to Gaining Policy. Each sync policy uses different category names for all modules (for example, address book, calendar, and tasks).

In this situation, when a user is removed from the Losing Policy, Riva retains the transactions for that user against that policy. When the user is added to the Gaining Policy, a new set of transactions records are started against the gaining policy. Riva runs an initial sync against the target user's mailbox. Because Riva does not discover items with the same category names, Riva syncs a fresh set of data and categorizes it by using the new category name down to the target user's mailbox. In the email address book, each Riva-synced CRM contact is now found in two set of contacts:

The Losing Policy set, which no longer syncs to the CRM
The Gaining Policy set, which now syncs to the CRM

Correct Procedures

When migrating users to existing policies with different category names, follow the Move target Exchange users to another sync policy using different category names procedure to prevent creating duplicate items in the email address book.

Example 3 - User moved back to the sync policy it was previously assigned to

In this example, a user is removed from Losing Policy, added to Gaining Policy(with the same category names), then removed from the Gaining Policy and returned to the Losing Policy.

In this situation, when a user is moved from the Losing Policy to the Gaining Policy, Riva performs in the same manner as in Example 1. When the user is removed from the Gaining Policy and added to the Losing Policy, Riva does not try to perform an initial sync, because the Losing Policy already has transaction data for that user. Instead, because Riva sees new contacts that are properly categorized, Riva syncs those contacts to the CRM, thus creating duplicates in the CRM. On the next sync cycle, Riva syncs those new duplicate contacts to the rest of the target users defined in all affected sync policies, thus creating duplicate contacts in the target user email address books.

Corrective Procedure: If this happens, STOP the Riva CRM Sync Agent immediately. For assistance with cleaning the CRM and Exchange systems, contact the Riva Success Team.

Scenario 9 - SmartConvert Converts an Email and Creates Duplicate Contacts

If Riva SmartConvert is configured to create new accounts and contacts, there are cases where Riva automatically creates new accounts and/or new contacts (perceived to be duplicates) in the CRM, which sync back to the target user's Exchange address book. Three cases include:

The account exists, but there is no web site address associated with it.
The account exists, but the web site address is different from the email domain address.
A contact exists, but the email address is different from the email address that was received.