Learning About MIDM Maintenance Tasks

Object profile maintenance involves a number of tasks you can perform to ensure that your database contains the most current and accurate information. These tasks include editing, adding, and deleting information, detecting and fixing profiles that are potential duplicates of each other, merging and unmerging object profiles or source records, and deactivating object profiles or source records that are no longer active.

The following topics provide additional information to help you understand data maintenance tasks for the master index application.

• Matching Probability Weights

• Merging Profiles on the MIDM

• Assumed Matches

• Potential Duplicates

• Handling Potential Duplicates on the MIDM

• Survivor Calculator Overrides

• Concurrent Users on the MIDM

Matching Probability Weights

When you add a new object profile to the master index application, the new profile is automatically checked for any similarities to profiles that already exist in the database. Matching probability weights between existing profiles and the new profile are then calculated using matching algorithm logic. This weight indicates how closely two profiles match each other. If the matching probability weight for two profiles is above a specific number (defined in the master index application configuration files), the profiles are considered to be potential duplicates. If the weight between two profiles is high enough, they are assumed to be a match and the existing profile is updated with the new information (for more information, see Assumed Matches).

Merging Profiles on the MIDM

You can merge object profiles that are found to represent the same object and you can merge source records within the same object profiles or between different object profiles. The source records you merge must be from the same source system. During a source record merge, you can specify which fields from each record to retain in the final, merged source record. After an object profile merge, all information from all the source records involved in the merge is stored in the surviving profile. You might need to review the final merge result profile to determine which, if any, source records should be deactivated or merged.

After an object profile merge, the SBR for the surviving profile is determined by the survivor calculator, taking into account all source records involved in the merge. If you merge profiles that have duplicate child objects (for example, each profile has an Office address) and the union survivor calculator is used, then the most recently modified of the two child objects is stored in the SBR. After a source record merge, the SBRs for both object profiles are determined by the survivor calculator provided both profiles are still active.

Surviving and Non-Surviving Profiles

You can perform an object profile merge on two, three, or four object profiles. The non-surviving profiles are the profiles that are not retained after the merge. These profiles are also referred to as merged profiles. The surviving profile is retained after the merge. This profile is also referred to as the main profile. During an object profile merge, the source records in the non-surviving profiles are transferred to the surviving profile, and the non-surviving profiles are given a status of “Merged”. The SBR for the surviving object profile is recalculated based on the existing source records for that profile along with the newly merged source records. The EUID of the surviving profile is always retained. The information that is discarded during a merge is stored in the transaction table, making it possible to restore the profiles to their original EUIDs if they were merged in error. You can specify which profile to retain during a merge and you can select fields from the non-surviving source record to be retained in the surviving source record.

Source Record Merges

You can merge source records together only if they originated from the same external system. The source records can belong to the same object profile or to different profiles. When the merge includes different object profiles, the profile from which the source record is merged is called the merge from profile; the object profile into which the source records are merged is called the merge to profile. If you merge the only active source record in one object profile into a source record in a different object profile, the merge from profile is deactivated (since there are no active source records remaining, there is nothing from which to create the SBR). During a source record merge, you can select fields from the non-surviving source record to be retained in the surviving source record.

Undoing a Merge

If you merge object profiles or source records in error, you can unmerge the profiles or records, moving the information back into the original object profiles or source records. Any modifications that were made to the surviving object profile or source record after the merge are retained after the profiles or records are unmerged. If a source record merge caused a “merge from” object profile to be deactivated, unmerging the source records reactivates that profile.

Assumed Matches

If you add a new object profile and the master index application determines that the object you are adding already exists in the database, the master index application assumes the profiles are a match and updates the existing object profile. This is known as an assumed match. An assumed match only occurs when the probability of a match between the new profile and the existing profile is above the match threshold specified by your system administrator. You can view assumed match transactions on the MIDM and reverse the match if needed. Reversing an assumed match creates a new object profile from the record that caused the assumed match and reverts the profile that was updated by the assumed match to its previous state.

Potential Duplicates

Potential duplicates are object profiles that possibly represent the same object. If you add a new object and the master index application determines that the object you are adding might already exist in the database, the profiles are listed as potential duplicates of one another. Profiles are listed as potential duplicates if the probability of a match between the two profiles is above the duplicate threshold but below the match threshold. Because object information is entered from various sources, an object profile might have several potential duplicates. In this case, it is important to identify the potential duplicates and to determine whether the profiles represent the same object.

Handling Potential Duplicates on the MIDM

The Duplicate Records function allows you to locate any profiles that are similar enough that they could represent the same object. You can compare potential duplicate profiles side-by-side to determine if they do represent the same object. Once you have determined whether the profiles are duplicates, you can use one of the following methods to correct the potential duplicate listing.

Merge

If you conclude that the profiles represent the same object, you need to determine which EUID to retain and then merge the profiles. For a description of the merge process, see Merging Profiles on the MIDM.

Resolve

If you conclude that two potential duplicate profiles do not represent the same object, you can mark the profiles as being resolved. Doing this does not change any information for either profile, but it flags them as not being potential duplicates of one another. There are two methods of resolving potential duplicates.

• Resolve – This type of resolution allows the profiles to be listed as potential duplicates again if one of the profiles is updated and, after its potential duplicates are reevaluated, the profiles still have a matching weight above the duplicate threshold.

• Resolve Permanently – This type of resolution marks the profiles as not being duplicates, and does not allow the pair to be listed as duplicates after any future updates to either record. This is a permanent resolution.

Survivor Calculator Overrides

Every time a source record is updated, the survivor calculator determines whether the new information should be populated into the SBR. This includes updates from the MIDM and from local systems. Typically, when you update information in an object profile, you update the source record, which kicks off the survivor calculator. The MIDM provides two methods to override the survivor calculator for the SBR. You can update the SBR directly and lock that field for editing, or you can link the value of an SBR field to the value of a source record field.

Linking Source Record Fields to the SBR

The MIDM provides the ability to link the value of a specific source record field to the same field in the SBR. When you link an SBR and source record field, the value of the SBR field is always the same value as the field in that source record. If the field value is subsequently updated in the source record, the changes are shown in the SBR. The field values remain the same until the link is removed, at which point the survivor calculator immediately recalculates the best value for the field based on the source records in the profile. You can only link SBR and source record fields in the parent object and only if you have explicit security permissions to do so.

Locking Field Values in the SBR

When you update an SBR field directly, you can select an overwrite check box to save the changes to the database. You can also select the overwrite check box to lock an SBR field and prevent it from being updated by any source record changes or by the survivor calculator until the overwrite check box is cleared. When a field is unlocked, the survivor calculator immediately recalculates the best value for that field based on the source records in the profile.

If you lock a field in a child object, such as an Address or Phone object, then the key field (in this case, Address Type or Phone Type), is automatically locked. When you add a child object, such as a telephone number or address, directly to the SBR, all fields in that object are automatically locked and cannot be overwritten by the survivor calculator. If you unlock all the fields in that object, it is removed from the SBR by the survivor calculator.

Use this capability cautiously, since fields updated in the SBR cannot be overwritten by new information from local systems until the overwrite check box is cleared. You can only update an SBR and select or clear the overwrite check box for parent object fields, and only if you have explicit security permissions to do so.

Concurrent Users on the MIDM

If you have the same object profile open for editing as another MIDM user, only the user who commits their changes first will be able to save their changes. If you try to commit changes after the first user clicks Commit, an error message appears and you will be unable to commit your changes. In order to update the profile with your changes, you must reload the profile by performing a search for that profile. You can then edit the profile and commit your changes.