Duplicate Record Handling for Data Imports

The Duplicate Criteria section of the Data Import Wizard displays the criteria used to prevent instances of redundant records, which can be especially helpful when importing contacts.

During the import process, fields listed in the criteria are compared with existing values in the primary record table in search of duplicate records. When importing contacts, duplicate values in the email, email_alt1, and email_alt2 fields of the data file are also detected. When a duplicate is found, action is taken as specified in the Duplicate Records drop-down list on the initial page of the wizard.

Duplicate criteria consists of a logical expression formatted as field_name={mapped column}, where mapped column is the column number or header name. Multiple fields evaluate using Boolean logic.

The default expression varies based on the type of records imported and the columns mapped to the knowledge base. The following fields are automatically included as default duplicate criteria whenever they are included in the mapping grid:

• Email Address—When importing contacts, to simplify detection of redundant values in the primary and secondary email address fields (email, email_alt1, and email_alt2), the expression references them together as any_email. For example, any_email={1}.
• Contact ID, Organization ID, Incident ID, Answer ID—These fields are included as default criteria when importing their primary record type. Because these fields are unique for every record, additional criteria would not be more restrictive. For this reason, OR logic is used whenever they are added to the duplicate criteria. For example, any_email={1} OR c_id={2}.
• First and Last Name—If email address sharing is enabled, first_name and last_name is included when importing contacts. This narrows the criteria by permitting multiple contacts that share a common email address as long as they have different first or last names. For example, any_email={1} AND first_name={2} AND last_name={3}.
• Login—When importing contacts, this field is included in the default criteria if it is mapped. For example, login={1}.
• Organization Name—When importing organizations, this field is required and is always included in the default criteria. For example, name={1}.
• Reference #—When importing incidents, this field is included in the default criteria if it is mapped. For example, ref_no={1}.
• Key (configuration setting name)—When importing configuration base entries, these required fields are included in the default criteria. For example, entry_key={Key}.
• ID and Key—When importing configuration base values, these required fields are included in the default criteria. For example, configbase_id={ID} AND configbase_entry_id={Key}.
• Key (message base name)—When importing message base entries, this required field is included in the default criteria. For example, entry_key={Key}.

For added flexibility, you can define custom criteria by clearing the Use Default check box and entering a logical expression using any combination of mapped fields. For instance, if you want to avoid creating duplicate contacts with the same last name (mapped to column 1) and user ID (mapped to column 2), you can enter last_name={1} AND login={2}. If column headers are specified in the data file or header file, you can refer to them by header name instead, such as last_name={Last Name} AND login={User ID}.

Note: If you define custom criteria that does not include the email field, and email address sharing is not enabled, records matching existing contacts create new contacts with a numerical value appended to the email address. See Email Address Sharing.

When customizing duplicate criteria, supported Boolean operators and characters can be inserted by clicking the buttons above the Criteria field or by simply entering them in the Criteria Field.