Learning About EDM 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 system records, and deactivating object profiles or system 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 EDM

• Assumed Matches

• Potential Duplicates

• Handling Potential Duplicates on the EDM

• Update Tips for the EDM

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 EDM

You can merge object profiles that are found to represent the same object and you can merge system records between object profiles. During a system record merge, you can specify which fields from each record to retain in the final, merged system record. After an object profile merge, all information from all the system 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, system records should be deactivated.

The SBR for the surviving profile is determined by the survivor calculator, taking into account all system records involved in the merge. If you merge two 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.

Surviving and Non-surviving Profiles

When you perform an object profile merge, you are working with two object profiles. The non-surviving profile is the profile that is not retained after the merge. The surviving profile is retained after the merge. During an object profile merge, the system records in the non-surviving profile are transferred to the surviving profile, and the non-surviving profile is given a status of “Merged”. The SBR for the surviving object profile is recalculated based on the existing system records for that profile along with the newly merged system 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.

System Record Merges

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

Undoing a Merge

If you merge two object profiles or system records in error, you can unmerge the profiles or records, moving the information back into the original object profiles or system records. Any modifications that were made to the surviving object profile or system record after the merge are retained after the profiles or records are unmerged. If a system record merge caused the “merge from” object profile to be deactivated, unmerging the system 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.

Potential Duplicates

Potential duplicates are two 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 two 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 EDM

The Matching Review 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 EDM.

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.

Update Tips for the EDM

There are special circumstances for updating object profiles, such as cases where two users update the same profile at the same time, updating the SBR versus updating a system record, and so on.

Concurrent Users

If you have the same object profile open for editing as another EDM 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.

Updating the SBR versus System Records

Every time a system record is updated, the survivor calculator determines whether the new information should be populated into the SBR. This includes updates from the EDM and from local systems. Typically, when you update information in an object profile, you update the system record, which kicks off the survivor calculator. However, the EDM also allows you update the SBR directly, overriding the survivor calculator's version of the SBR.

When you update an SBR field, the overwrite check box is automatically selected so you can 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 system 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 system records in the profile.

If a field in a child object, such as an Address or Phone object, is locked, 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 if you have explicit security permissions to do so.