Person Matching Algorithm

Updated in 2021.2

When certain Alloy Navigator services import Person information from external sources to the Alloy Navigator database, they use Person Matching Algorithm (PMA) to avoid duplicates. This document explains the algorithm.

These Alloy Navigator use PMA:

• Active Directory Import — The Active Directory Import tool provides Active Directory Synchronization. For details, see Integration with Active Directory and Other Directory Services.

• Alloy Discovery Connector — The Alloy Discovery Connector provides Alloy Discovery Synchronization. For details, see Configuring Alloy Discovery Synchronization.

• Mail Connector — The Mail Connector processes incoming email and transforms messages and replies into Alloy Navigator tickets or other objects. For details, see Processing Incoming E-mail.

Terms and conventions

The following terms are used throughout this document:

• Parameters or input parameters are data coming from external sources, e.g. the data taken from e-mail messages by the Mail Connector. In the text below, the names of these parameters always start with small letters to distinguish them from database fields.

• Full Name, Login and E-mail are properties of a Person whose values are taken from the corresponding fields in the database tables containing the Person data. Note that Login and E-mail properties of a Person include all logins (usernames) and e-mail addresses of that Person, respectively. In the text below, the names of these properties always start with capital letters to distinguish them from input parameters. Names of the particular database fields are always displayed in monospace.

• The input full name, input login and input e-mail are input parameters corresponding to Full Name, Login and E-mail, respectively.

• Attributes are attributes of a Person that are used without regard to their origin (the database or external sources).

Algorithm

The Person Matching Algorithm implemented in Alloy Navigator is based on the following rules:

• Searching for matches is performed among Person database records in the "Active" status.

• Matching is based on maximum three attributes: Full Name, Login, and E-mail. However, the number of attributes that are used for matching may be decreased if the mapping table of the service that currently uses PMA to search for a Person does not specify mapping for some database fields. Particularly:

  • If the mapping table of the service does not contain the Full_Name field, the Full Name attribute does not participate in matching.

  • If the mapping table of the service does not contain the Primary_Login field, the Loginattribute does not participate in matching.

  • If the mapping table of the service does not contain the Primary_E-mail field, the E-mail attribute does not participate in matching.

• During matching, all "Active" Person records are treated as match candidates (or potential matches). The Full Name, Login, and E-mail of these records are compared to the full name, login, and e-mail input parameters.

• From the list of potential matches, the algorithm selects the Person in accordance with this rule:

N < L < NL < E < NE < LE < NLE

where:

• N is the Person that has Full Name that matches the input full name;
• L is the Person that has Login that matches the input login;
• NL is the Person that has both Full Name and Login that match the input full name and login;
• E is the Person that has E-mail that matches the input e-mail;
• NE is the Person that has both Full Name and E-mail that match the input full name and e-mail;
• LE is the Person that has both Login and E-mail that match the input login and e-mail;
• NLE is the Person that has all the Full Name, Login, and E-mail that match the input full name, login, and e-mail.

For example, if Person_E has E-mail that matches the input e-mail and Person_LE has Login and E-mail that match the input login and e-mail, Person_LE is selected as a match.

• From the list of potential matches with the same matching attributes, the algorithm selects the one that was created earlier. For example, if Person_LE1 that was created yesterday and Person_LE2 that was created today share the same E-mail and Login matching the input e-mail and login, the Person_LE1 that was created yesterday would be chosen as a match.

Special cases

There are several special cases within the algorithm.

Active Directory Import

When the Active Directory Import tool creates a Person, it populates the ADImport_ID field of that auto-created Person with the user’s distinguished name from the Active Directory (such as CN=Max Payne,CN=Users,DC=atlas,DC=com). The Active Directory Import relies on that ADImport_ID field when matching the user from the Active Directory to any existing Person record in the database:

• First, the Active Directory Import tool attempts to match the user’s distinguished name in the Active Directory to the ADImport_ID value of Person records in the database. If a positive match is detected, the Active Directory data overwrites the database record with the information from the Active Directory.

• If there is no positive match, the tool divides the existing Person records into two groups, depending on their ADImport_ID values, and applies a different algorithm for every group:

  • For Persons with the ADImport_ID field non-blank (these are Persons created by the Active Directory Import tool), the simplified Person Matching Algorithm is applied. This means that the tool checks the Login and E-mail attributes and selects the Person in accordance with this rule: L < E < LE.

  • For Persons with the ADImport_ID field blank (these are Persons created by other services or users), the standard Person Matching Algorithm is applied. This means that the tool checks the Full Name, Login, and E-mail attributes and selects the Person in accordance with the standard N < L < NL < E < NE < LE < NLE rule.

    NOTE: When the Active Directory Import tool checks the Full Name, represented as N in the rule, it attempts to match the Full Name value in the Alloy Navigator database with the cn (common name) attribute in the Active Directory.

Mail Connector

• When the Mail Connector searches for the Person in the database (to match the sender of the received e-mail), it qualifies a found Person record as a match only if it has an E-mail that is equal to the input e-mail (including a null E-mail value that is considered equal to a blank input e-mail). Otherwise, it is considered that no matching Person was found and a new Person record is created.

NOTE: The Mail Connector always searches for the matching Person by E-mail, regardless of the presence of E-mail attribute in the Field Mapping specified within the corresponding workflow actions.

IMPORTANT: If there is no E-mail attribute in the Field Mapping, its value will still be used for searching for the matching Person, but this value will not be saved, e.g. if a new Person record is created in this case, the E-mail field of the record will be blank.

• If all of the input parameters are blank (e.g. the full name and e-mail values to be taken from the e-mail message by the Mail Connector are not specified), the algorithm checks whether or not there is a Person record that has these respective database fields empty, and, if there isn’t, a new person is created. If a Person record matching this criterion exists, it is selected as a match.

Returned results

The Person Matching Algorithm returns the following results:

• The Person record that was qualified as a match (in case when one or more candidates with matching attributes were found, and one candidate was selected as a match from them).

• Nothing (no Person was matched).

Other aspects

Other aspects of the PMA are the following:

• Missing input parameters are translated into blank values of these parameters.

• Null values of the database fields are considered as blank values.