Person Matching Algorithm

Several tools in Alloy Navigator Express use the Person Matching Algorithm (PMA) when matching Person information from external sources to Person records in the database:

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 related fields in the database tables containing the Person data. Note that Login and E-mail properties of a Person include all logins 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).

Person Matching Algorithm

The Person Matching Algorithm implemented in Alloy Navigator Express 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 Login attribute 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 potential matches (or match candidates). 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;
    • etc.

    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 have the same E-mail and Login matching the input e-mail and login, Person_LE1 is selected as a match.

Special Cases

There are several special cases within the algorithm.

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 blank, and, if there isn’t, a new person is created. If a Person record matching this criterion exists, it is selected as a match.

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). Then, when the Active Directory Import tool attempts to match the user from the Active Directory to any existing Person record in the database, it first 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. Otherwise, the Active Directory Import tool applies the standard Person Matching Algorithm, which is based on Full Name, Login and E-mail attributes.

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.