Working With the Master Index Data Manager

The topics listed here provide procedures, conceptual information, and reference information for using the Master Index Data Manager (MIDM) to monitor and maintain the data in Sun Master Index applications.

Note that Java CAPS includes two versions of Sun Master Index. Sun Master Index (Repository) is installed in the Java CAPS repository and provides all the functionality of previous versions in the new Java CAPS environment. Sun Master Index is a service-enabled version of the master index that is installed directly into NetBeans. It includes all of the features of Sun Master Index (Repository) plus several new features, like data analysis, data cleansing, data loading, and an improved Data Manager GUI. Both products are components of the Sun Master Data Management (MDM) Suite. This document relates to Sun Master Index only.

What You Need to Know

These topics provide information you should to know before you start to work with the MIDM.

• About the Master Index Data Manager

• About Sun Master Index

• Learning about MIDM Object Profiles

• MIDM Object Profile Components

• Source Record and SBR Components in a Master Index

• Identification Numbers for each Entity in the Master Index

• Master Index Data Manager Security Permissions

• Master Index Data Manager Navigation Tips

• Learning About Object Queries on the MIDM

• Learning About Object Profile Views on the MIDM

• Learning About MIDM Maintenance Tasks

• Learning About MIDM Reports

What You Need to Do

These topics provide instructions on how to use the MIDM to monitor and maintain data in master index applications.

• Logging in to the Master Index Data Manager

• Logging Out of the MIDM

• Using the MIDM Dashboard

• Searching for Object Profiles on the MIDM

• Viewing Object Information on the MIDM

• Adding an Object Profile on the MIDM

• Modifying Profile Information on the MIDM

• Working with Potential Duplicate Profiles on the MIDM

• Working with Assumed Matches on the MIDM

• Combining Object Information on the MIDM

• Unmerging Object Information on the MIDM

• Running MIDM Reports

More Information

These topics provide additional information you should know when using the MIDM:

• About Transaction History Search Fields on the MIDM

• About Transaction History Results Fields on the MIDM

• Transaction History Transaction Types on the MIDM

• About Audit Log Search Fields on the MIDM

• About Audit Log Results Fields on the MIDM

• Audit Log Functions on the MIDM

• About Duplicate Records Search Fields on the MIDM

• About Assumed Matches Search Fields

• About Assumed Match Results Fields on the MIDM

• About Report Search Fields on the MIDM

Related Topics

Several topics provide information and instructions for implementing and using a master index application. For a complete list of topics related to working with the service-enabled version of Sun Master Index, see Related Topics in Developing Sun Master Indexes .

About the Master Index Data Manager

The Master Index Data Manager (MIDM) is a web-based interface that allows you to access, monitor, and maintain the data stored by the master index applications you create using Sun Master Index. The MIDM provides the ability to search for, add, update, deactivate, merge, unmerge, and compare object profiles. You can also view and correct potential duplicate profiles, view transaction histories, view an audit log, and print reports.

The MIDM is your primary tool to view and maintain the data stored in the master index database and cross-referenced by a master index application.

About Sun Master Index

Sun Master Index provides a flexible framework to allow you to create matching and indexing applications called master index applications. It is an application building tool to help you design, configure, and create a master index application that will uniquely identify and cross-reference the business objects stored in your system databases. Business objects can be any type of entity for which you store information, such as customers, patients, vendors, businesses, hardware parts, and so on. Sun Master Index allows you to define the data structure of the business objects to be stored and cross-referenced. In addition, you define the logic that determines how data is updated, standardized, weighted, and matched in the master index database.

The following topics provide additional information about Sun Master Index, the master index applications created by Sun Master Index, and the Master Index Data Manager (MIDM).

• About Master Index Applications

• Features of Master Index Applications

• Functions of the Master Index Data Manager

About Master Index Applications

The applications created by Sun Master Index are enterprise-wide master index applications that maintain the most current information about the objects in your business enterprise. A master index application creates a single, consistent view of all object data by providing an automatic, common identification process regardless of the location or system from which the data originates. Object profiles from various locations are cross-referenced using an enterprise-wide unique identifier (EUID) assigned to each profile by the master index application. By creating EUIDs, a master index application can identify many types of participants, such as customers, employees, contacts, and so on.

The identification and general information for all objects is centralized in one shared index. A master index application is designed specifically to support scattered business locations and disparate information systems across an enterprise, as well as various applications from multiple vendors. Maintaining a centralized database for multiple systems enables a master index application to integrate data throughout the enterprise while allowing local systems to continue operating independently. A master index application makes it easy to find information that was previously scattered among multiple systems.

Features of Master Index Applications

The components of the master index applications you create are highly configurable, allowing each master index application to be customized for your specific data processing needs. Primary features of a master index application include the following:

• Centralized Information – A master index application maintains a centralized database, enabling the integration of data records throughout the enterprise while allowing local systems to continue operating independently. The index stores copies of local source records and the single best record (SBR), which represents the most accurate and complete data for each object. This database is the central location of all object information and identifiers, and is accessible throughout the enterprise. Records from various systems are cross-referenced using the EUID assigned by a master index application to each object profile.

• Configurability – Before deploying a master index application, you can customize the components and processing capabilities of the system. The configurable components include:

  • The types of objects to index

  • The types of data stored

  • The standardization and match engines to use

  • Matching, standardization, and phonetic conversion rules

  • Survivorship and weighting rules for determining the SBR

  • The types of queries available

  • How queries are blocked, or grouped, for match processing

  • MIDM appearance

  • Searches available to the MIDM

  • Local ID validation rules

• Cross-referencing – A master index application serves as a global cross-reference, matching profiles across disparate source systems and simplifying the process of sharing data between systems. A master index application uses the local identifiers assigned by your existing systems as a reference, allowing you to maintain your current systems and practices.

• Data Cleansing – A master index application uses configurable matching algorithm logic to uniquely identify object profiles and to identify duplicate and potential duplicate profiles. A master index application provides the ability to easily merge or resolve duplicates, and can be configured to automatically match profiles that are found to be duplicates of one another.

• Data Updates – A master index application provides the ability to add, update, deactivate, merge, and delete data in the database tables through messages received from external systems or the MIDM. Messages received from external systems and the MIDM are checked for potential duplicates during processing.

• Updates to External Systems – The master index application can publish updated information to external systems, provided the external systems can accept incoming messages. This is handled through a JMS Topic to which a master index application publishes XML messages that contain the updates.

• Identification – A master index application employs configurable probabilistic matching technology. This technology uses a matching algorithm to formulate an effective statistical measure of how closely profiles match. Using a state-of-the-art algorithm in real-time mode and establishing a common method of locating profiles, a master index application consistently and precisely identifies objects within an enterprise.

• Matching Algorithm – A master index application is designed to use the Master Index Match Engine or a custom matching algorithm to provide a matching probability weight between object profiles. You define matching thresholds, which control how potential duplicates and automatic merges are determined.

• Unique Identifier – A master index application assigns an enterprise-wide unique identifier (EUID) to each object added to the database. The index uses the EUID to cross-reference the local IDs assigned to each object by the various computer systems throughout the enterprise.

Functions of the Master Index Data Manager

While a master index application cleanses data automatically as it is entered through external system messages or through the MIDM, there are instances where it cannot be determined automatically whether two object profiles truly match one another. In these cases, manual review through the MIDM is needed to verify the status of the two profiles and then to possibly join two potential duplicate profiles or separate two profiles that were automatically joined. The MIDM provides additional functions to help you maintain the data you store.

Using the MIDM, you can perform the following activities.

• View an Object’s History – The system provides a complete transaction history of each object profile by recording all changes to each object’s data. This allows you to view before and after images of a profile for each change made. The table also records the user ID of the person who made the changes. This history is maintained for both the local source records and the SBR.

• Search for Object Profiles – Using the MIDM, you can search for specific objects or sets of objects. The MIDM allows you to perform different types of searches using different combinations of data elements and returns a list of potential matches to your search criteria. For certain searches, the results are assigned a matching weight that indicates the probability of a match.

• Maintain Object Data – The MIDM supports all the necessary features for maintaining object profiles. It allows you to add new profiles; view, update, deactivate, or reactivate existing profiles; and compare profiles for similarities and differences. You can also view each local source record associated with an SBR.

• Compare Object Data – The MIDM allows you to compare two or more object profiles in a side-by-side comparison so you can evaluate their differences or similarities. You can also compare different objects within one object profile in the same comparison view. For example, you can compare the profile’s SBR with a record from System A and you can compare a profile’s record from System A with its record from System B.

• View and Resolve Potential Duplicates – Using algorithm matching logic, a master index application has the ability to identify potential duplicate profiles, and the MIDM provides the ability to manually correct the duplicate profiles. Profiles that are potential duplicates can be viewed online in a side-by-side comparison. Potential duplication is resolved by either merging the profiles in question or removing their potential duplicate flags.

• Merge and Unmerge Profiles – You can compare potential duplicate profiles and then merge the profiles if you find them to be actual duplicates of one another. Using the merge feature, you can determine which profile to retain as the active profile. The MIDM also allows you to merge source records between object profiles and to specify which information from each source record to preserve in the resulting profile. If two object profiles or source records are merged in error, you can unmerge them, returning the information to the original records. You can also view a history of merges for a profile by viewing its merge tree.

• Audit Log – The system administrator can specify that a log be maintained of each instance that object data is accessed from the MIDM. This log provides information such as the user ID of the user who accessed the data, the type of action that was performed against the data, and the date and time of access.

• Security – Security is provided through the application server and includes basic access to the database through user login IDs and passwords, as well as access to specific functions and actions of a master index application. Access can be restricted by functions, actions within functions, data element, and user ID.

Learning about MIDM Object Profiles

The information about an object in a master index application is stored in an object profile. The profile includes information from all of the source records for that object and also includes a record that contains the best information about the object according to the master index application.

The following topics describe object profiles and their components:

• MIDM Object Profile Components

• Source Record and SBR Components in a Master Index

• Identification Numbers for each Entity in the Master Index

MIDM Object Profile Components

An object profile, also known as an enterprise record, is a set of information that describes characteristics of an individual object in the master index application. An object profile includes information from one or more source systems. The information can be divided up into child objects, which hold additional information about an object, such as address information, telephone information, or alias names.

A profile contains two types of records:

• Source Records – A source record, also known as a system record, is a set of information from an external system that shares data with a master index application. A profile might contain several source records.

• Single Best Record – The single best record (SBR) is a set of information derived from the best information from each source record in an object profile (as determined by the survivor calculator). Each object profile has only one SBR.

Source Records

Source records are different from the SBR in that each source record contains a system and local ID pair and only contains data from a specific system. The information in the source records of an object profile is used to determine the best values for the SBR in that profile. If an object profile only contains one source record, the SBR will be identical to that source record. However, if an object profile contains multiple source records, the SBR might be identical to one source record but will more likely include a combination of information from all source records. Certain actions against a source record will cause the SBR to be changed, such as updating, deactivating, or merging a source record. Each active object profile must have at least one active source record. If all source records in a profile are deactivated, then the entire profile will also be deactivated.

Single Best Record

The single best record (SBR) for an object profile is made up of a combination of information from all active source records associated with that object profile. The SBR represents the information that is determined by the master index application to be the most reliable and current of all source records in an object profile. The SBR is dynamic and is recalculated each time an update is made to an associated source record, a merge or unmerge affects the object profile, or a source record in the profile is deactivated or reactivated. You can use the overwrite capability of the MIDM to update the SBR directly or you can update a source record and allow the survivor calculator to determine how to update the SBR (for more information, see Survivor Calculator).

You can override the survivor calculator by specifying values for the SBR in two ways. You can use the overwrite capability to update a field, and that field remains locked and cannot be updated by changes to source records until the field is unlocked. You can also link a field in the SBR to the same field in one of the profile's source systems, and that SBR field will always contain the same value as the source system until the link is removed. For more information about the overwrites and linked fields, see Locking Field Values in the SBR.

Survivor Calculator

The survivor calculator determines which information from each source record in an object profile is stored in the SBR for that profile. The calculator uses information defined by the system administrator to calculate the SBR. By default, the survivor calculator uses a weighted strategy for most fields, using the relative reliability assigned to each system in combination with the reliability given to the most recently updated value.

For some fields, such as alias and auxiliary IDs, a union strategy is typically used. This means that all unique alias names and auxiliary IDs from all systems are included in the SBR. For detailed information about the survivor calculator and configuring the survival strategy, see Survivor Strategy Configuration in Understanding Sun Master Index Configuration Options and Defining the Master Index Survivor Calculator in Configuring Sun Master Indexes .

Source Record and SBR Components in a Master Index

In a master index application, each source record and SBR in an object profile contains a set of sub-objects that store different types of information about the object. Generally, a record contains a parent object and several child objects. A record can have only one parent object, but can have multiple child objects and multiple instances of each child object with each instance being identified by a unique field. For example, in a master person index a record can only contain one person name and social security number (contained in the parent object), but could have multiple addresses, telephone numbers, and aliases (contained in child objects). Typically each address must be of a different type, such as a home address, billing address, or mailing address.

Identification Numbers for each Entity in the Master Index

Each object profile in a master index application is assigned a unique identification number in addition to the local IDs assigned by individual systems. Each object has one unique identification number throughout your organization and a unique identification number within each system with which they are registered.

EUID

Every object profile in the master index system is assigned an enterprise-wide unique identification number. This number is the same for that object regardless of the system from which the object information originates. This number is called the enterprise-wide unique identifier (EUID) and is used to cross-reference object profiles in order to accurately identify the objects throughout your organization.

Local ID

A local ID is a unique local identification number that is assigned to an object in each system at which it is registered. These numbers are assigned using a numbering system unique to each local system, and are used internally by the systems to identify each object. A master index application uses an object’s EUID to cross-reference its local IDs in different systems. Note that the name of the Local ID field is configurable and might be different for your implementation.

Auxiliary ID

An auxiliary ID is an identification code that does not necessarily uniquely identify a single object within the database, but might identify a group of objects. For example, if a family shares the same account or insurance policy, every family member would have the same identification code for that account or policy.

Working with the Master Index Data Manager

The MIDM is a web-based application, which means you access the application through an internet browser. The MIDM uses standard web-based features, such as hyperlinks, data fields, and action buttons, to help you enter information and navigate through the different pages.

The following topics provide basic information about the design of the MIDM and logging in to and out of the application:

• Requirements

• Logging in to the Master Index Data Manager

• Master Index Data Manager Security Permissions

• Master Index Data Manager Navigation Tips

• Logging Out of the MIDM

Requirements

The MIDM is supported on Mozilla Firefox, Internet Explorer 6, and Safari. The recommended browsers are Firefox 3 and Internet Explorer 7. When using IE 6, you might experience display issues, such as partially obscured tables and buttons, and some buttons may not perform as expected. You might also experience minor display issues when using Safari.

For the browser you use, make sure that popup windows are allowed for the MIDM URL and that JavaScript is enabled. Additionally, if you are working with sensitive data, you might also want to disable the feature that automatically fills in field values as you type. These options are configured on the Options (Firefox) or Internet Options (Internet Explorer) window accessed from the Tools menu.

Logging in to the Master Index Data Manager

Before you can use the MIDM, you must first log in to the application by entering the correct URL in your web browser and then specifying your login ID and password. Make sure you have a user ID and password for the master index application before logging in. The application server running the master index application must be started before you can log in to the MIDM.

The URL for the MIDM is:

http://host:http_port/app_nameMIDM

where

• host is the name of the server machine.

• http_port is the HTTP port number of the application server.

• app_name is the name of the master index application.

The “MIDM” at the end of the URL is case-sensitive and must be entered in all capital letters.

The HTTP port number for the Sun Java System Application Server is listed in the domain.xml file in the http-listener element (8080 by default). The domain.xml file is located in app_server_home\domains\domain_name\config. The port number is also listed on the Client and Server page of the HTTP Monitor of the NetBeans IDE.

To Log in to the MIDM

1. Launch a web browser.

2. In the Address field, enter the appropriate URL.

   The login page appears.

   Figure 1 MIDM Login Page

   
   

3. In the upper right portion of the page, select the language for the MIDM display.

4. Enter your user ID and password in the appropriate fields.

5. Click Login.

   The initial page appears. (By default, the initial page is the Record Details page, but this is configurable.)

   ---

   Note –

   After a certain period of inactivity, the MIDM automatically logs off and returns you to the Login page when you try to perform an activity on the MIDM. Simply reenter your user name and password to access the MIDM again. The system administrator can set the inactivity period at the server level in the session-timeout element of default-web.xml (in appserver_home\domains\domain_name\config) or at the application level in web.xml in the master index application .war file (located in the deployment .ear file) or in the deployment folder itself. The application level overrides any values set at the server level. The default inactivity period is 30 minutes.

   ---

Master Index Data Manager Security Permissions

Security for the MIDM is defined at the function level. You might not be able to perform all the functions described in this guide depending on the security permissions you are assigned. For more information about functions you can perform, see your system administrator. Security for the MIDM is defined in the application server. For information about defining security for the MIDM, see Defining Master Index Data Manager Security in Maintaining Sun Master Indexes

Master Index Data Manager Navigation Tips

The MIDM provides hyperlinks and command buttons to help you access and move through the MIDM pages. When you place the cursor over links and images on the MIDM pages, tooltips appear to provide additional information. Information is also provided to facilitate the use of screen readers and other assistive technology.

Navigating the MIDM Functions

The actions you can perform on the MIDM are grouped into these primary functions: Dashboard, Duplicate Records, Record Details, Assumed Matched, Transactions (history), Source Record, Reports, and Audit Log. The main menu on all MIDM pages provides hyperlinks to each of these functions, as shown in the following figure. The first page to appear for each function except the Source Record function is a search page. The names of these headings can be modified for your application.

Figure 2 Main Menu Navigation Tools

• Dashboard – The Dashboard provides a summary of recent transactions, quick links to commonly used functions, and quick lookup functions. The information, links, and lookup functions on this page can be configured by the system administrator.

• Duplicate Records – The Potential Duplicate function allows you to perform a search for potential duplicate profiles. Potential duplicate profiles are profiles whose matching probability weight indicates they might match but is not high enough to automatically match the two profiles. From the associated pages, you can compare, merge, or resolve potential duplicate profiles.

• Record Details – The Record Details function allows you to perform a search for an object profile or set of object profiles in the master index application. From the associated pages, you can compare two object profiles, compare records in one object profile, view all information for one object profile, update an object profile or source record, view a transaction history of an object profile, view an object’s potential duplicates, and merge object profiles.

• Assumed Matches – The Assumed Matches function allows you to perform a search for any profiles that were updated by an assumed match transaction. An assumed match occurs when either the system and local ID of an incoming record match the system and local ID of a record in the master index database or when the matching probability weight is high enough to indicate that two records represent the same object. From the associated pages, you can view and reverse assumed match transactions.

• Transactions – The Transactions function allows you to perform a search for transaction histories. From the Transaction History pages, you can compare information about an object before and after a transaction occurred, select object profiles to unmerge, and view a merge history for an object profile. From associated Transaction History pages, you can unmerge object profiles.

• Reports – The Reports function allows you to display and print reports about certain transactions performed both from the MIDM and from messages sent in from external systems. You can run reports from either the MIDM or from a command line.

• Source Record – The Create Source Record function allows you to create new object profiles by creating a source record. When you save the information in the source record, the master index application automatically generates the SBR using the survivor calculator. You can also edit and merge source records from the Source Record page.

• Audit Log – When enabled, the Audit Log function allows you to perform a search for audit log entries. From the Audit Log pages you can view information about transactions in which data about an object was accessed through the MIDM. This helps enforce HIPAA privacy rules for healthcare master indexes.

Navigating the MIDM Detail Pages

The detail pages display the SBR of the object profile on the left and you can expand the pages to view source records on the right. Child objects appear below the parent object, and you can expand and collapse the information for each type of object. If you are viewing a comparison of object profiles, you can expand the source records of one object profile at a time. The following figure illustrates a sample of the Record Details page and shows the SBR to the left of three source records. Each detail page includes scrollbar navigation within the larger browser window so you can control the display of data.

Figure 3 Sample Record Details Page

Logging Out of the MIDM

Before you exit the MIDM, make sure you have saved any changes. To exit the MIDM, click Sign Out in the upper right corner of the page. The Login page reappears.

Using the MIDM Dashboard

The following topics provide step-by-step instructions to help you perform the various functions available from theMIDM Dashboard. The information in these topics is based on a default configuration.

• Viewing Summary Information From the Dashboard

• Accessing Reports and Audit Logs From the Dashboard

• Performing a Quick Search (EUID Lookup)

• Performing an EUID Comparison Lookup

Viewing Summary Information From the Dashboard

The Dashboard provides a short summary of important transactions that have occurred in the past 24 hours. You can view how many of these transactions occurred and link to the search pages to view more information.

Figure 4 Summary Box on the Dashboard

To View Summary Information

1. In the tabbed headings, click Dashboard.

   The Summary box displays the number of potential duplicate and assumed match transactions that have occurred in the past 24 hours.

2. To view additional information about potential duplicates, click Potential Duplicates in the Summary box, and then perform a search as described in Working with Potential Duplicate Profiles on the MIDM.

3. To view additional information about assumed match transactions, click Assumed Matches in the Summary box and then perform a search as described in Working with Assumed Matches on the MIDM.

Accessing Reports and Audit Logs From the Dashboard

The Dashboard provides quick links to the search pages for different types of production reports that give you information about the status of your data.

Figure 5 Reports Box on the Dashboard

To Access Reports and Audit Logs From the Dashboard

1. In the tabbed headings, click Dashboard.

2. To view a Merged Record report, click Merged Records and then perform a search as described in Running MIDM Reports.

3. To view a Deactivated Record report, click Deactivated EUIDs and then perform a search as described in Running MIDM Reports.

4. To view an Unmerged Record report, click Unmerged Records and then perform a search as described in Running MIDM Reports.

5. To view an audit log, click Audit Log and then perform a search as described in Viewing the MIDM Audit Log.

Performing a Quick Search (EUID Lookup)

To search for an object profile using only an object’s EUID, you can enter the EUID number in the Quick Search box of the Dashboard. This type of search should result in only one matching profile.

Figure 6 Quick Search

To Perform Quick Search

1. In the tabbed headings, click Dashboard.

2. In the Quick Search section, enter the object’s EUID.

3. Click Search to initiate the search.

   The Record Details page appears, displaying detailed information about the object whose EUID you entered.

4. To perform a more advanced search with multiple criteria fields and options, click Advanced Search.

Performing an EUID Comparison Lookup

You can perform a lookup of multiple EUIDs from the Dashboard to compare object profiles in a side-by-side view on the Record Details page. To lookup multiple EUIDs, specify each EUID in the Compare EUIDs box on the Dashboard. You can enter from two to four EUIDs to compare in the search results list.

Figure 7 Compare EUIDs Box on the Dashboard

To Perform an EUID Comparison Lookup

1. In the tabbed headings, click Dashboard.

2. In the Compare EUIDs box, enter at least two, and up to four, EUIDs.

3. Click Compare.

   The Record Details page appears with each matching profile displayed side-by-side.

Learning About Object Queries on the MIDM

Before you can view or update object information, you need to perform a search for the object. There are several different search capabilities within the MIDM. You can perform lookups for specific object profiles using unique identifiers, such as the EUID or local ID, and you can perform broader searches using data from the parent or child objects as criteria.

The following topics provide information about working with general searches that are designed to find specific records in the master index database. Most of these searches are performed from the Record Details page, but some are performed from the Dashboard. Searches for specific functions, such as finding potential duplicates or assumed matches, are described in the topics for those functions.

• About the MIDM Search Function

• Searching by Ranges on the MIDM

• Required Fields on the MIDM

About the MIDM Search Function

There are several different methods of searching for objects, depending on the search criteria you enter. By default, the Record Details page includes three different search types: Advanced Lookup (Alpha), Advanced Lookup (Phonetic), and Simple Lookup. You can also perform an EUID lookup from the Dashboard to view record details. The design of the search functionality provides flexibility in designing database queries. You can narrow a search for a specific object or a range of objects using various fields on the search pages and then view your search results in the search results list. When you select a specific object from the Search Result page, detailed information for that object appears on the Record Details page in view mode.

The names of the search types are configurable. Searches are described in the following sections by their default names, and images show customized search criteria. See your system administrator if you have questions about how your search pages are configured.

Simple Lookup

The Simple Lookup on the Record Details page allows you to perform lookups using unique identifiers to find a specific object profile. By default, the unique identifiers you can use as search criteria include the EUID and the local ID and system. When you perform this type of search, the search results list is generally bypassed and the Record Details page appears in view mode displaying information about the matching profile.

You can perform an EUID Lookup from either the Dashboard or the Record Details page. Other simple lookups include system and local ID lookups, which can be performed from the Record Details page or the Source Record page. To increase search accuracy, you can only select a system listed in the drop-down list and the Local ID field is case-sensitive.

Advanced Alphanumeric Lookup

The Advanced Alphanumeric Lookup on the Record Details page allows you to perform various types of searches against the database using a field or combination of fields as criteria. This type of search is an exact match search, meaning it only returns profiles that exactly match the criteria you specify. You can specify any combination of fields as long as any fields that are required for the search are entered. Most fields in this search allow wildcard characters if the exact value is unknown.

The fields displayed on the Search page are configured by the system administrator. You can enter as much information as needed to narrow down the search appropriately.

Advanced Phonetic Lookup

The Advanced Phonetic Lookup on the Record Details page allows you to perform various types of searches against the database using predefined combinations of fields as criteria. This type of search compares the phonetic values of certain fields entered as criteria. The object profiles returned by a phonetic search are assigned a matching probability weight to indicate how closely they match the search criteria. Phonetic searches are not exact match searches and allow for misspellings or data entry errors.

The fields displayed on the Search page are configured by the system administrator. You can enter as much information as needed to narrow down the search appropriately. For phonetic searches, certain combinations of criteria are required to perform a search. The search is only carried out for the combinations that have complete data.

For example, in a master company index, a blocking search might be configured to search on the following combinations:

• Company Name and Sales Region

• Company Name and Address Line1

• Tax Payor ID

• Stock Symbol and Address Line1

If Company Name, Address Line1, and Stock Symbol are entered as criteria, only the second and fourth combinations are carried out. The returned result set would include any records that match on Company Name and Address Line1 or that match on Stock Symbol and Address Line1. If only Company Name is entered as criterion, no records are returned since it does not fulfill any of the combination requirements.

EUID Comparison Lookup

The Comparison Lookup function on the Dashboard allows you to perform a search for one or more object profiles by entering their EUIDs. The matching records for this type of search appear on the Record Details page in a side-by-side comparison view. Use this type of search if you want to compare object profiles and you know the EUIDs of the object profiles to compare.

The Search Results List

The search results list appears under the search fields and displays a list of object profiles found in the database that closely match the search criteria you entered. The results list appears in a table, with the number of profiles returned for the search displayed above the table. This page displays information to help you identify the object profile, such as the EUID or address information. The search results list appears differently depending on which type of search is performed and how the lists are configured. For more information about search results, see Working with Search Results on the MIDM.

Searching by Ranges on the MIDM

Your system administrator can configure the search pages to allow you to enter a range by which to search for certain fields. For example, you might want to search for profiles with a specific name, but with a date that falls within a five-year range. If a field is defined for searching by a user-defined range, the MIDM displays a ”from’ field and a ”to’ field so you can specify the range (for example, “Date From” and “Date To”). If you only enter a value in the ”from’ field, the MIDM searches for profiles with a value greater than or equal to that value. If you only enter a value in the ”to’ field, the MIDM searches for profiles with a value less than or equal to that value.

Ranges can also be defined as the entered value plus or minus a specific value. For example, a date field can be configured to search for dates that fall within a range five years earlier than the date you enter and five years later than the date you enter. Finally, ranges can be defined as specific upper and lower limits. These limits are used when no value is entered. For example, if you perform a search without the date, the MIDM searches between the defined lower and upper limits. If you enter only a ”from’ date, the MIDM searches between the date you entered and the defined upper limit. For more information about how your system has been configured for range searching, see your system administrator.

Required Fields on the MIDM

Certain fields might be required for the searches on the MIDM. If a field is marked with an asterisk (*), it is required. If multiple fields are marked with daggers (†), at least one of those fields must be populated in order to perform the search. The required fields can vary depending on the type of search you are performing.

Searching for Object Profiles on the MIDM

The following topics provide step-by-step instructions to help you perform the various types of searches for object profiles available on the MIDM. To move from one field to another on the search pages without using the mouse, press the Tab key.

• Performing an EUID Lookup

• Performing a Local ID Lookup

• Performing an Alphanumeric Search

• Performing a Phonetic Search

• Performing an EUID Comparison Lookup

• Working with Search Results on the MIDM

Performing an EUID Lookup

To search for an object profile using only an object’s EUID, you need to enter the EUID number in the EUID Search section, either on the Dashboard or on the Record Details page. This type of search should result in only one matching profile.

The following procedure is for performing the lookup from the Record Details page. For instructions on performing the lookup from the Dashboard, see Performing a Quick Search (EUID Lookup).

Figure 8 Simple Lookup Page

To Perform an EUID Lookup

1. Click the Record Details page and select Simple app_name Lookup from the Search Type drop-down list (where app_name is the name of the master index application) .

2. In the EUID section, enter the object’s EUID.

3. Click Search to initiate the search.

   The Record Details page appears in view mode, displaying detailed information about the object whose EUID you entered.

Performing a Local ID Lookup

To search for an object profile by its local ID in a specific system, you need to enter search criteria in the Local ID section of the Lookup page. This type of search should result in only one matching profile. If the Local ID field contains alphabetic characters, the criterion is case-sensitive.

The name of this section might have been modified for your implementation. See your system administrator for more information.

Figure 9 Simple Lookup Page

To Perform a Local ID Lookup

1. Click the Record Details page and select Simple app_name Lookup from the Search Type drop-down list (where app_name is the name of the master index application).

2. In the System field, select the source system, such as a registration system, for which the object’s local ID is known.

3. In the Local ID field, enter the object’s unique identification code for the specified system.

   ---

   Note –

   If alphabetic characters are entered in this field, the search is case-sensitive. This field name might have been modified for your implementation.

   ---

4. Click Search to initiate the search.

   The Search Result page is bypassed, and the Record Details page appears in view mode.

Performing an Alphanumeric Search

To perform an alphanumeric search for an object profile, you need to specify identifying information for the object on the Alphanumeric Search page. This type of search might result in several matching profiles.

Make your search as specific as possible. This type of search does allow wildcard characters; use a percent sign (%) to indicate unknown characters. Any required fields are marked with an asterisk (*). If at least one field in group of fields is required, the fields in that group are marked with a dagger (†). In addition, range searching is supported for any field type that has two fields, one with “From” appended to the name and one with “To” appended to the name (for example, “DOB From” and “DOB To”). If your MIDM is set up for range searching, see the system administrator for more information about how it is configured.

Figure 10 Alphanumeric Search Page

To Perform an Alphanumeric Search

1. On the Record Details page, select Advanced app_name Lookup (Alpha) from the Search Type drop-down list (where app_name is the name of the master index application).

2. Enter the search criteria for the object you want to find.

3. Click Search to initiate the search.

   The search results list appears with a list of matching profiles. If only one matching profile is returned, the Record Details page appears in view mode.

   ---

   Note –

   The system administrator can choose whether to display certain transaction–based fields on this page, such as the EUID field, the local ID and system fields, or the create date field. Any values entered into these optional fields take precedence over information entered into other search fields. For example, if an invalid EUID is entered but valid first and last names are entered, no results are returned due to the invalid EUID. The EUID field takes precedence over the local ID and system fields.

   ---

Performing a Phonetic Search

To perform a phonetic search for an object profile, you need to specify identifying information for the object in the phonetic search fields. Only specific combinations of fields are used for queries. This search might return several profiles.

Figure 11 Phonetic Search

To Perform a Phonetic Search

1. On the Record Details page, select Advanced app_name Lookup (Phonetic) from the Search Type drop-down list (where app_name is the name of the master index application).

2. Enter the search criteria for the object you want to find.

   ---

   Note –

   Certain combinations of data might be required to perform a phonetic search. See your system administrator for more information. For more information about phonetic searches, see Advanced Phonetic Lookup.

   ---

3. Click Search to initiate the search.

   The search results list appears with a list of matching profiles. If only one matching profile is found, the results list is bypassed and the Record Details page appears in view mode.

   ---

   Note –

   The system administrator can choose whether to display the EUID field or the local ID and system fields on this page. Any values entered into these optional fields take precedence over information entered into other search fields. For example, if an invalid EUID is entered but valid first and last names are entered, no results are returned due to the invalid EUID. The EUID field takes precedence over the local ID and system fields.

   ---

Performing an EUID Comparison Lookup

You can perform a search by EUID for multiple profiles from the Dashboard. You can enter from one to four EUIDs in the Compare EUIDs section. The resulting profiles appear in a side-by-side display on the Record Details and you can compare record information.

Figure 12 EUID Comparison Lookup

To Perform an EUID Comparison Lookup

1. In the tabbed headings, click Dashboard.

2. In the Compare EUIDs box, enter at least two, and up to four, EUIDs.

3. click Compare.

   The Record Details page appears with each matching profile displayed side-by-side.

Working with Search Results on the MIDM

The following topics describe the search results list for searches performed from most MIDM pages, how to sort and select the profiles that match the searches you perform, and how to print a search result report. The results list appears below the search criteria, and the number of records returned for the search appear above the results list.

• Viewing the Results of a Search

• Selecting a Profile from the Results List

• Sorting the Results of Your Search

Viewing the Results of a Search

The matching profiles that result from an object search appear in table format below the search criteria. The table displays a limited number of fields contained in the SBR of the object profile.

Figure 13 Search Results List

To View the Results of a Search

1. Using one of the searches described in Searching for Object Profiles on the MIDM, perform a search for the object whose profile you want to access.

   If more than one record matches the criteria, the search results list appears below the criteria.

2. In the results list, view the information presented for each returned profile to determine which profile you want to view.

3. To view additional address or telephone information for a profile, click the address component or telephone number you want to view.

   A popup window appears, as shown in the following figures.

   Figure 14 Address Information Popup

   
   

   Figure 15 Telephone Information Popup

   
   

4. When you are finished viewing the additional address or telephone information, click Close.

5. To navigate through the results list pages, do any of the following:

   • To view the following page of search results, click Next>.

   • To return to the previous page of results, click <Previous.

   • To view the first page of search results, click <<First.

   • To view the last page of search results, click Last>>.

6. To select a profile to display on the Record Details page in view mode, click the EUID of that profile or select the check box next to the EUID and click Compare.

7. To select multiple profiles to compare on the Record Details page, select the check boxes next to the EUIDs you want to compare, and then click Compare.

8. To return to the Search Results list from the Record Details page, click Back.

9. To perform a new search, click Clear in the search criteria section of the page.

10. To print the results in a report, click Print.

Selecting a Profile from the Results List

From the Record Details results list, you can select one object profile in order to view detailed information for that profile or you can select two profiles to compare the information in both profiles. .

To Select a Profile to View

1. Perform a search for the object profiles you want to view.

2. To view detailed information for one object profile, click the EUID of that profile.

   The View/Edit page appears, displaying the person object for that profile.

3. To compare object profiles, select the check boxes to the left of each profile you want to compare, and then click Compare Records.

   The Record Details page appears, displaying a side-by-side comparison of the profiles.

Sorting the Results of Your Search

By default, the results of a search are sorted by EUID, but you can sort the results by any column in the search results list table.

To Sort the Profiles on the Search Result Page

1. Using one of the searches described in Searching for Object Profiles on the MIDM, perform a search for the object whose profile you want to access.

2. In the results list that appears, click a column heading to sort the results in ascending order by that column.

3. Click that column heading again to sort the results in descending order.

Learning About Object Profile Views on the MIDM

Before you can view object information, you need to perform a search for the object using one of the search techniques described under Searching for Object Profiles on the MIDM. Once you retrieve a search results list, you can view an object’s detailed information, compare object profiles, view a merge transaction history for a profile, and view a history of all transactions for a profile.

You can view object information in any of the following formats:

• Object Profile Details on the MIDM

• Source Record Details on the MIDM

• Object Profile and Source Record Comparisons

• Object Profile Transaction Histories

• Object Profile Merge Histories on the MIDM

• The Master Index Audit Log

Object Profile Details on the MIDM

When you select a profile to view from the search results list, detailed information about the selected object appears on the Record Details page in view mode. This page displays the SBR of the profile you selected on the left side of the page, and you can expand the view to include all source records contained in the profile. Parent object information appears first followed by the data for each child object. From the Record Details page, you can perform several actions, such as viewing a transaction history for the object, viewing potential duplicate profiles, deactivating the profile, updating object information, and so on.

Source Record Details on the MIDM

You can view source record details from both the Record Details page and the Source Record page. On the Record Details page, you can view all source records for an object profile. On the Source Record page, you can search for and view a specific source record. From the Source Record page, you can perform several actions against a source record, including adding a new source record, editing an existing source record, deactivating or reactivating a source record, and merging two, three, or four source records. From the Record Details page, you can also edit the source records belonging to a profile.

Object Profile and Source Record Comparisons

You can compare multiple object profiles by performing an EUID comparison lookup for the profiles to compare from the Dashboard or by selecting multiple profiles in a search results list. The profiles are displayed in a side-by-side view on the Record Details page. Once the profiles are displayed on the Record Details page, you can compare the source records of each object profile.

The Record Details comparison view allows you to view the selected profiles in a side-by-side comparison with the differences between the profiles highlighted. This view also allows you to compare a profile’s SBR with its own source records, and to compare source records in one profile or between multiple profiles. This gives you a complete comparison between object profiles and between source records.

On the Source Record page, you can compare up to four source records from multiple profiles as long as they are all from the same source system.

Object Profile Transaction Histories

You can view a history of all transactions performed against object profiles either by performing a search for specific records, as described in Searching for Object Profiles on the MIDM, or by performing a Transaction History search on the Transactions page, as described in Viewing Transaction Histories on the MIDM. You can trace the events that modified an object profile from the time the profile was added to the master index application to the most previous transaction, including merged and deactivated profiles.

The Transaction History page allows you to view a side-by-side comparison of one object profile before and after a transaction occurred against that profile. You can also compare an SBR against an SBR, an SBR against a source record, and a source record against a source record. From associated Transaction History pages, you can unmerge previously merged profiles.

Object Profile Merge Histories on the MIDM

You can display a history of the merges that have affected a specific object profile. The merge history appears in an EUID tree format in a pop-window. The top level displays the EUID of the current active profile. The two EUIDs at the second level indicate the profiles that were merged to form the top-level profile. If there are EUIDs listed at the third level, they indicate the profiles that were merged to form the profile above them. There might be several levels of merges displayed in an object’s merge history.

The right side of the page displays information about the merge transactions that involved the EUID that is selected in the EUID tree on the left. You can select a specific transaction to view a transaction history comparison for that merge transaction.

The Master Index Audit Log

The audit log allows you to track and view all instances in which information about the objects in the master index application was accessed through the MIDM. If audit logging is enabled, an audit log entry is created each time the MIDM accesses database tables that contain object information. The audit log keeps a record of each time the tables are accessed, along with the database function used to access the tables, the login ID of the user accessing the tables, the date and time the tables were accessed, and the EUIDs of the object profiles that were accessed. The audit log is enabled and disabled in the midm.xml file in the master index project.

Viewing Object Information on the MIDM

The MIDM displays object profiles in a series of pages from which you can search for, select, and view object profiles. You can view information associated with any of the SBR or source record components in an object profile. The SBR contains the information that is determined to be the most current and accurate information about that object from all external systems.

The source records associated with a profile contain information that is stored in the external systems that share information with the master index application. The information in a source record might not match the information in the SBR. You can view information about an object in several different ways, including the following:

• Viewing Object Profiles on the MIDM

• Viewing a Source Record on the MIDM

• Comparing Object Information on the MIDM

• Viewing Transaction Histories on the MIDM

• Viewing a Profile's Merge History on the MIDM

• Viewing the MIDM Audit Log

Viewing Object Profiles on the MIDM

The Record Details page displays object profiles in a series of pages from which you can select and view profiles. You can view information associated with any of the SBR or source record components in an object profile. The SBR contains the information that is determined to be the most current and accurate information about that object from all local systems. By default, when the Record Details page first appears in view mode, only the information in the SBR is visible.

Figure 16 Record Details Page in View Mode

To View an Object Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to view on the Record Details page.

2. To view different types of information in the SBR for the displayed object, simply scroll through the visible data fields.

3. To view source records belonging to the profile, scroll to the bottom of the data fields and then click View Sources.

   All source records for the profile appear in a side-by-side comparison view.

4. From the Record Details page, perform any of the following functions. The buttons you click are all located at the bottom of the SBR.

   1. To modify object information, click Edit EUID and follow the appropriate procedure under Modifying Profile Information on the MIDM.

   2. To view a history of transactions for the displayed profile, click View History (for more information, see Viewing Transaction Histories on the MIDM).

   3. To deactivate a profile, click Deactivate (for more information, see Deactivating a Profile or Source Record).

   4. To view an image of both profiles involved in the most recent merge transaction, click View Merged Records.

      An image appears of both profiles as they were prior to the merge. This option is only available if the displayed profile is currently merged with another profile.

   5. To view a merge history tree for the profile, click View Merge Tree.

      This option is only available if the displayed profile is currently merged with another profile.

5. When you are done viewing a profile, do any of the following. The buttons you click are located at the top of the page.

   1. To return to the search results list, click Back.

   2. To look up another profile by EUID, enter the EUID in the field in the upper left and click Search.

   3. To perform an advanced search for another profile, click Advanced Search.

Viewing a Source Record on the MIDM

The Source Record page displays source records in a series of search and view pages. You can view information associated with any of the SBR or source record components in an object profile. The source records associated with a profile contain the information that is stored in the external systems that share information with the master index application. The information in an object’s source records might not match the information stored in the object’s SBR.

Figure 17 Source Record Page in View Mode

To View a Source Record

1. In the tabbed headings, click Source Records.

2. Click the View/Edit sub-tab, if it is not already selected.

3. In the System field, select the system from which the source record originated.

4. In the Local ID field, enter the local ID number for the source record you want to view.

   ---

   Note –

   If the Local ID field allows alphabetic characters, the search is case-sensitive.

   ---

5. Click Search.

   If the local ID is found, the source record fields appear in view mode.

6. From the Source Record View/Edit page, perform any of the following functions. The buttons you click are all located at the bottom of the source record.

   1. To modify field values in the source record, click Edit and follow the appropriate procedure under Modifying Profile Information on the MIDM.

   2. To view the object profile that contains the displayed source record, click View EUID (for more information, see Viewing Object Profiles on the MIDM).

   3. To deactivate the source record, click Deactivate at the bottom of the page.

Comparing Object Information on the MIDM

The MIDM allows you to compare two or more object profiles side-by-side to check for similarities and differences. You can also compare different components of the same object profile and you can compare two or more source records from the same or different profiles.

Comparing Two or More Object Profiles

To compare two or more object profiles, you can either perform an EUID comparison lookup from the Dashboard, or you can select multiple records from a Record Details search. From the resulting comparison page, you can compare the resulting profiles and you can view the source records for the displayed profiles.

Figure 18 Record Details Page - Multiple Object Profiles

To Compare Two or More Object Profiles

1. Perform a search for the object profiles you want to compare, using one of the following methods:

   • If you know the EUIDs of the profiles you want to compare, lookup the EUIDs from the Dashboard as described in Performing an EUID Comparison Lookup .

   • If you do not know the EUIDs of the profiles to compare, perform a search on the Record Details page as described in Searching for Object Profiles on the MIDM, select the check boxes next to the EUIDs to compare, and then click Compare.

     The records appear on the Record Details page in a side-by-side comparison view.

2. To view the source records for a displayed profile, click View Sources under that profile.

   ---

   Tip –

   When you are done viewing the source records for a profile, click View Sources under that profile again to return to the comparison view.

   ---

3. To view a transaction history for one of the displayed profiles, click View History under that profile.

   ---

   Tip –

   When you are done viewing the transaction history for a profile, click View History under that profile again to return to the comparison view.

   ---

4. To merge object information, click the EUIDs of the profiles you want to merge, and then click Preview. Follow the instructions under Merging Object Profiles on the MIDM.

Comparing Source Records From Object Profile Views

You can view the source records from one or more object profile displayed on the Record Details page in either view or comparison mode. This page does not provide merge functionality for source records. To merge source records, compare the records on the Source Record page as described in Viewing a Source Record on the MIDM.

Figure 19 Source Record Comparison From Record Details

To Compare Source Records From Object Profile Views

1. Perform a search for the object profile containing the source records you want to view, as described in Searching for Object Profiles on the MIDM.

2. In the search results list, select the EUIDs of the profiles you want to view and then click Compare.

   The Record Details page appears with SBR information displayed.

3. For each SBR whose source records you want to compare, scroll to the bottom of the SBR information and then click View Sources.

   The source records belonging to the displayed profile appear.

4. To edit any of the displayed source records, click Edit EUID at the bottom of the page and follow any of the procedures under Modifying Profile Information on the MIDM.

5. To merge source records in the displayed object profile, make a note of their local ID numbers, and then follow the instructions under Merging Source Records on the MIDM.

Comparing Source Records From One Source System

To compare source records directly without accessing them from an object profile, you need to know the system and local ID numbers for the records. On the Source Record page, you can only compare records that originated from the same system.

Figure 20 Source Records Comparison

To Compare Source Records From One Source System

1. In the tabbed headings, click Source Record.

2. Click the Merge sub-tab.

3. In the Source field, select the name of the source system from which the records you want to compare originated.

4. In the Local ID fields, enter at least one and up to four local IDs.

   ---

   Note –

   If any of the Local ID fields allows alphabetic characters, the search is case-sensitive.

   ---

5. Click View Records.

   Any matching source records appear side-by-side in a comparison view.

6. To view the object profile for one of the source records, click View EUID under that source record.

   ---

   Tip –

   Clicking View EUID takes you out of the Source Records page and into the Record Details page. To return to the Source Record comparison page, click Back on the Record Details page.

   ---

7. To merge any of the displayed source records, see Merging Source Records on the MIDM.

Viewing Transaction Histories on the MIDM

Using the Transactions function, you can view historical information for a specific object and compare the object’s profile before and after a specific transaction occurred to determine what information was modified as a result of the transaction. You can access the transaction history for a profile from the Record Details page, or you can access transaction histories for one or more profiles from the Transactions page.

When you display a transaction history from the Record Details page, all of the transactions for the displayed object profile appear in chronological order, with the earliest transaction on the left and the most recent transaction on the right. When you display a transaction history record from the Transactions page, the image of the profile as it was prior to the transaction appears on the left side of the comparison page. The image on the right reflects the object’s information after the transaction occurred.

To View a Complete Transaction History For an Object Profile

1. Perform a search for the object profile whose history you want to view using one of the search procedures described in Searching for Object Profiles on the MIDM.

2. If necessary, select the profile to view from the search results list.

   The profile appears on the Record Details page.

3. Scroll to the bottom of the displayed SBR, and then click View History.

   A history of all transactions performed against the object profile appears.

   Figure 21 Transaction History on the Record Details Page

   
   

4. Scroll through the profile's history using the window's internal scrollbar at the bottom of the profile.

To View Transaction History Records from the Transactions Page

1. Obtain information about the object profile whose history you want to view, such as the EUID, a system in which the object was registered, or a specific transaction performed against the object’s profile.

2. In the tabbed headings, click Transactions to open the Transactions Search page.

   Figure 22 Transaction History Search Page

   
   

3. Enter values into any of the search fields as criteria. For more information about these fields, see About Transaction History Search Fields on the MIDM.

   ---

   Note –

   The EUID field takes precedence over all other search fields on this page. You can only enter a local ID as search criteria after you have entered the corresponding system.

   ---

4. Click Search.

   The Transaction History search results list appears with a list of matching transactions (for more information, see About Transaction History Results Fields on the MIDM).

   Figure 23 Transaction History Results

   
   

5. Click a transaction number of a result to view the transaction on the Transactions comparison page.

   Figure 24 Transaction History Comparison Page

   
   

   ---

   Note –

   If you are viewing an unmerge transaction, the active record prior to being unmerged is displayed on the left. The after image of the two records that were unmerged during the transaction is displayed on the right.

   ---

6. To view the source records for either the before or after profile, click View Sources beneath the profile image.

7. If you are viewing a merge transaction that has not been unmerged, you can unmerge the records here. For more information, see Unmerging Object Information on the MIDM.

About Transaction History Search Fields on the MIDM

The fields located on the Transaction History Search page allow you to specify search criteria for the transactions you want to view. Note that the label for the Local ID field is customizable and might have been changed for your implementation. The search page can also be configured to display additional transaction fields. The following table lists the fields that are defined by default for a transaction history search.

About Transaction History Results Fields on the MIDM

The fields located in the Transaction History search results list help you identify a specific object profile and transaction to view. Additional fields might be added to this page by the system administrator. The LID field is configurable and might have been changed for your implementation.

Transaction History Transaction Types on the MIDM

Each transaction performed by the master index application is assigned a transaction type, indicating the type of action that was performed against the profile. The following table lists and describes each transaction type.

Viewing a Profile's Merge History on the MIDM

When an object profile that is currently merged is displayed on the Record Details page, you can display a history of all merges performed against the profile, allowing you to trace the origin of certain information contained in the profile. The master index application tracks all merges performed against each object profile in the database. You can view a history of merges that affect a specific object profile and you can view each EUID that was merged to form the final merge result profile. The merge history appears in a tree structure on the Record Details page, showing each pair of profiles that were merged under the displayed object profile.

To View an Object’s Merge History

1. Using one of the search procedures described in Searching for Object Profiles on the MIDM, perform a search for the object whose merge history you want to view.

2. If necessary, select the object profile you want to view from the search results list.

   The Record Details page appears.

3. Beneath the SBR, click View Merge Tree.

   The Merge Tree popup window appears. You might need to scroll up to see the merge tree.

   Figure 25 Merge History Tree

   
   

4. Expand the tree structure to view the EUIDs that were combined to create the current record.

5. To view transaction information for any of the merge transactions, click either of the EUIDs involved in the transaction.

   Figure 26 Merge Transaction History

   
   

Viewing Merged Profiles for an Object Profile

If the profile you are viewing on the Record Details page has been merged, you can view the merged profiles that were combined to create the currently displayed profile.

To View Merged Profiles for an Object Profile

1. Using one of the search procedures described in Searching for Object Profiles on the MIDM, perform a search for the object whose merge history you want to view.

2. If necessary, select the object profile you want to view from the search results list.

   The Record Details page appears.

3. Beneath the SBR, click View Merged Records.

   The profiles that were merged to create the current profile are displayed.

   

Viewing the MIDM Audit Log

Using the Audit Log function, you can view a record of each instance an MIDM user accessed information about any object in the master index database. The audit log includes instances in which an object profile appeared in a search results list; was viewed or compared; was added, updated, or deactivated; or was merged or unmerged. The audit log can be enabled or disabled by the system administrator.

To View the Audit Log

1. Obtain information about the instances you want to view, such as the EUID, a time frame for when they occurred, the type of function that caused the audit log entries, the user who performed the functions, and so on.

2. In the tabbed headings, click Audit Log to open the Audit Log search page.

   Figure 27 Audit Log Search Page

   
   

3. Enter values into any of the search fields as criteria. For more information about these fields, see About Audit Log Search Fields on the MIDM.

   ---

   Note –

   The EUID field takes precedence over all other search fields on this page. You can only enter a local ID as search criteria after you have entered the corresponding system.

   ---

4. Click Search.

5. On the Audit Log search results list, view the instances in which the data was accessed. For information about the fields displayed on this page, see About Audit Log Results Fields on the MIDM.

   Figure 28 Audit Log Search Results List

   
   

About Audit Log Search Fields on the MIDM

The fields located on the Audit Log Search page allow you to enter search criteria about the audit log entries you want to view. These fields are configurable. The following table describes the fields that are displayed by default.

About Audit Log Results Fields on the MIDM

The fields located on the Audit Log Result page display information about the instances in which object data was accessed, where those instances match the search criteria you entered. These fields are configurable. The following table describes the fields that are displayed by default.

Audit Log Functions on the MIDM

The audit log creates an audit entry whenever data is accessed through the MIDM. The following table lists and describes each audit log function. Some of these functions refer to the actual viewing of data on an MIDM page; others refer to an action taken against that data, such as clicking the merge or unmerge Confirm button or resolving a potential duplicate pair.

Adding an Object Profile on the MIDM

This section provides the step-by-step instructions you need in order to add object profiles to the master index database. When you add an object profile, you are actually creating a source record. When you create a source record, the master index either adds the new record to the database or updates an existing record if a match is found. The master index application calculates the SBR portion of the object profile when you commit the source record to the database.

Adding an object profile includes the following steps:

• Step 1: Obtain Information about the Object

• Step 2: Specify a System and Local ID

• Step 3: Specify Parent Object Information

• Step 4: Specify Child Object Information

• Step 5: Save the Object Profile

Step 1: Obtain Information about the Object

Before you begin to add a new object to the master index application, you should obtain certain information about the object. If necessary, review the fields displayed on the pages of the MIDM to learn what types of information you need to enter about the object. You should provide as much information as is available for each object.

When you have gathered all the necessary data, continue to Step 2: Specify a System and Local ID.

Step 2: Specify a System and Local ID

Each object profile is associated with at least one source record. Before you add data to an object profile, you must specify the object’s local ID in a specific system. This creates the source record component of the object profile.

Figure 29 Add Source Record - System and Local ID

To Specify a System and Local ID

1. Complete Step 1: Obtain Information about the Object.

2. In the MIDM tabbed headings, select Source Record.

   The Source Record page appears.

3. Click the Add tab on the Source Record page.

4. In the System field, select the name of the source system from which the new record originated.

5. In the Local ID field, enter the local ID assigned to the new record by the specified system.

   ---

   Note –

   The name of the Local ID field might have been modified for your use. See your system administrator for more information.

   ---

6. Click Validate.

   If the record does not already exist, the page changes to display profile fields.

7. Continue to Step 3: Specify Parent Object Information.

Step 3: Specify Parent Object Information

When you add a new object profile to the master index database, you need to enter certain information about the object. The required information varies depending on the type of objects in the index and the configuration of the application. An asterisk appears next to each required field.

Figure 30 Add Source Record - Parent Object

To Specify Parent Object Information

1. Complete Step 2: Specify a System and Local ID.

2. On the Source Record page, fill in the open fields.

3. Continue to Step 4: Specify Child Object Information.

Step 4: Specify Child Object Information

After you specify information for the parent object in the object profile, you can add child objects to the profile.

Figure 31 Add Source Record - Child Objects

To Specify Child Object Information

1. Complete Step 3: Specify Parent Object Information.

2. On the Source Record page, scroll down until you see Add child_type, where child_type is the type of child object you want to add (for example, Add Address).

3. Click Add child_type.

   The page changes to display the fields associated with that child object type.

4. Fill in any open fields for the child object.

5. Click Save child_type.

6. Repeat the above steps for each child object to add.

7. Continue to Step 5: Save the Object Profile.

Step 5: Save the Object Profile

After you specify all the required information for an object profile, save the profile to the database or the information you entered will be lost.

To Save the Object Profile

1. Complete Step 4: Specify Child Object Information.

2. Scroll to the bottom of the page and click Submit.

   ---

   Note –

   When the transaction completes, the MIDM returns to the initial Add page and a message displays informing you whether a new profile was added to the database, a new profile was added and it has potential duplicates, or an existing profile was updated with the information you entered.

   ---

3. To add another source record, repeat the steps beginning with Step 1: Obtain Information about the Object.

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.

Modifying Profile Information on the MIDM

Once an object profile has been added to the master index application, you can modify information about that object, update the object's single best record, add source records to the profile, or change the status of a source record or object profile. If you make any of these modifications, the survivor calculator determines what changes, if any, should be made to the SBR. You can only modify the SBR directly if you have access permission to do so.

Perform any of the following tasks to update profile information:

• Modifying Information in an Object Profile

• Modifying Information Directly in a Source Record

• Overwriting SBR Field Values

• Overriding the Survivor Calculator's SBR

• Adding a Source Record to an Object Profile

• Deactivating a Profile or Source Record

• Reactivating a Profile or Source Record

Modifying Information in an Object Profile

If the information for an object profile changes, you can update the information in either the SBR or the affected source record. If you update the source record, then the survivor calculator determines what changes, if any, should be made to the SBR. You must have overwrite permissions to update the SBR directly. If you know the local ID and system of the source record you want to modify, you can access the source record directly, as described in Modifying Information Directly in a Source Record.

Perform any of the following tasks to modify information in an object profile:

• Modifying Parent Object Information in a Profile

• Adding a Child Object to an Object Profile

• Modifying a Child Object in a Profile

• Deleting a Child Object From a Profile

Modifying Parent Object Information in a Profile

The Record Details page has an edit mode, where you can modify field values in the displayed object profile. The following figure shows the Record Details page in edit mode.

Figure 32 Record Detail Page - Parent Object

To Modify a Parent Object in a Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. To update the SBR, do the following:

   1. For each field in the parent object you want to modify, click the padlock icon to the left of the field to modify, and then modify the value of the field.

   2. Click Update parent_object under the fields you modified (where parent_object is the name of the parent object.

      ---

      Note –

      You can only modify SBR fields directly if you have permissions to do so.

      ---

4. To update a source record, modify the parent object fields in any of the displayed system objects.

5. When you are done modifying information, click Update parent_object (where parent_object is the name of the parent object).

6. Click Save at the bottom of the page, and click OK on the information dialog box that appears.

   The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Adding a Child Object to an Object Profile

If additional information becomes available about an object, you might need to add a new child object to the object profile. For example, if additional address information becomes available, you might need to add a new address record to the affected source record. You cannot add a child object to the SBR.

Figure 33 Record Details Page - Child Objects

To Add a Child Object to an Object Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Click View child_type in the column containing the source record you want to modify.

   For example, to add an address record, select View Addresses.

4. In the empty field, enter the new information for the child object.

5. Beneath the record you updated, click Save child_type.

6. Scroll to the bottom of the page and click Save.

7. Click OK on the information dialog box that appears.

   The page refreshes and the SBR is recalculated based on the new information.

Modifying a Child Object in a Profile

If information about a child object changes, you might need to modify information for an existing child object. You cannot modify information in child object in the SBR. The following figure shows a child object on the Record Details page in edit mode.

Figure 34 Record Details Page – Edit Child Object

To Modify a Child Object in a Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. In the source record you want to modify, click View child_type, where child_type is the name of the child object type you want to add. For example, to modify an address record, select View Addresses.

   Empty child object fields appear along with a list of existing child objects of the selected type.

4. In the child object list, click the pencil icon next to the child object you want to modify.

   The field values for the selected child object are populated into the child object fields.

5. Modify any fields for the child object.

6. Beneath the record you updated, click Save child_type.

7. Scroll to the bottom of the page and click Save.

8. Click OK on the information dialog box that appears.

   The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Deleting a Child Object From a Profile

If a child object is entered incorrectly or becomes obsolete, you can delete the object from the affected object profile. Child objects cannot be deleted from the SBR. Deleting a child object cannot be undone.

Figure 35 Record Details Page – Delete Child Object

To Delete a Child Object

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Click View child_type in the source record you want to modify, where child_type is the name of the child object type you want to add. For example, to delete an address record, select View Addresses.

   Empty child object fields appear along with a list of existing child objects of the selected type.

4. In the child object list, click the delete icon next to the child object you want to modify.

   The delete icon is shaped like an “X”.

5. Scroll to the bottom of the page and click Save.

6. Click OK on the information dialog box that appears.

   The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Modifying Information Directly in a Source Record

If the object information for a specific source record changes, you can update the information by accessing either the object profile or the affected source record. If you update the source record, then the survivor calculator determines what changes, if any, should be made to the SBR. This section describes how to modify information by accessing the source record directly. For information about modifying an object profile, see Modifying Information in an Object Profile.

Perform any of the following tasks to modify information in a source record directly:

• Modifying the Parent Object in a Source Record

• Adding a Child Object to a Source Record

• Modifying a Child Object in a Source Record

• Deleting a Child Object From a Source Record

Modifying the Parent Object in a Source Record

If parent object for a particular source record changes, you can update the source record directly on the Source Record page. The following figure shows the Source Record page in edit mode.

Figure 36 Source Record Page – Edit Parent Object

To Modify the Parent Object in a Source Record

1. In the MIDM tabbed headings, click Source Record.

2. If necessary, click the View/Edit sub-tab.

3. In the System field, select the name of the system for the source record you want to modify.

4. In the Local ID field, enter the local ID for the record you want to modify.

5. Click Search.

   If a matching source record is found, it appears on the Source Record page in view mode.

6. At the bottom of the page, click Edit.

7. Modify the parent object fields in the upper portion of the page.

8. When you are done modifying information, click Save at the bottom of the page.

9. Click OK on the information dialog box that appears.

   The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Adding a Child Object to a Source Record

If additional information becomes available about an object, you might need to add a new child object to a source record. For example, if additional address information becomes available, you might need to add a new address record to the affected source record.

Figure 37 Source Record Page - Add Child Object

To Add a Child Object to a Source Record

1. In the MIDM tabbed headings, click Source Record.

2. If necessary, click the View/Edit sub-tab.

3. In the System field, select the name of the system for the source record you want to modify.

4. In the Local ID field, enter the local ID for the record you want to modify.

5. Click Search.

   If a matching source record is found, it appears on the Source Record page in view mode.

6. At the bottom of the page, click Edit.

7. Click View child_type, where child_type is the name of the type of child you want to add.

   The child object section expands to display empty fields for the object.

8. Enter information into the empty child object fields.

9. Click Save child_type.

10. When you are done adding information, click Save at the bottom of the page.

11. Click OK on the information dialog box that appears.

    The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Modifying a Child Object in a Source Record

If information about an object changes, you might need to modify information for an existing child object. You can make those changes on the Source Record page.

Figure 38 Source Record Page – Edit Child Object

To Modify a Child Object in a Source Record

1. In the MIDM tabbed headings, click Source Record.

2. If necessary, click the View/Edit sub-tab.

3. In the System field, select the name of the system for the source record you want to modify.

4. In the Local ID field, enter the local ID for the record you want to modify.

5. Click Search.

   If a matching record is found, it appears on the Source Record page in view mode.

6. At the bottom of the page, click Edit.

7. Click View child_type, where child_type is the name of the type of child you want to modify.

   The child object section expands to display empty fields for the object along with a list of existing child objects.

8. Click the pencil icon next to the child object you want to modify.

   The child object fields are populated with the values from the child object you selected.

9. Modify any of the child object fields.

10. Click Update child_type.

11. When you are done modifying information, click Save.

12. Click OK on the information dialog box that appears.

    The page refreshes, and, if you modified a source record, the SBR is recalculated based on the new information.

Deleting a Child Object From a Source Record

If a child object is entered incorrectly or becomes obsolete, you can delete the object from the affected source record. Deleting a child object cannot be undone.

Figure 39 Source Record Page – Delete Child Object

To Delete a Child Object From a Source Record

1. In the MIDM tabbed headings, click Source Record.

2. If necessary, click the View/Edit sub-tab.

3. In the System field, select the name of the system for the source record you want to modify.

4. In the Local ID field, enter the local ID for the record you want to modify.

5. Click Search.

   If a matching record is found, it appears on the Source Record page in view mode.

6. At the bottom of the page, click Edit.

7. Click View child_type, where child_type is the name of the type of child you want to delete.

   The child object section expands to display a list of existing child objects.

8. Click the delete icon next to the child object you want to modify.

   The delete icon looks like an “X”.

9. When you are done modifying information, click Save, and the click OK on the information dialog box that appears.

   The page refreshes, and the SBR of the object profile is recalculated based on the new information.

Overwriting SBR Field Values

Locking an SBR field for overwrite is one way to ensure that the value for that field is not recalculated by the survivor calculator each time the object profile is updated. If you determine that a value in the SBR is the most accurate data and should not be updated, you can lock the field and no updates can be made to that SBR field by the survivor calculator until it is unlocked. If you unlock a locked field, the value of that field is automatically recalculated by the survivor calculator as soon as the unlock action is committed. Only parent object fields can be locked.

Locking an SBR Field

When you lock a field in an SBR, that field can only be updated through the MIDM by a user who has overwrite permissions. Locking a field in the SBR removes the survivor calculator from the update process for that field and any updates made to or by source records will not update the locked fields in the SBR. You can only lock fields in the parent object.

The following figure shows an object profile with three locked fields in the SBR (as indicated by the open padlock icons in the column beneath the red arrow).

Figure 40 Locked Fields in an SBR Indicated by Open Padlocks

To Lock a Field in the SBR

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to lock on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Scroll to the SBR field you want to lock. Only parent object fields can be locked.

4. If necessary, change the value of the field to be locked.

5. Click the padlock icon to the left of the field.

   ---

   Note –

   A closed padlock indicates an unlocked field that can be locked. An open padlock indicates a locked field that can be unlocked.

   ---

6. Click OK On both dialog boxes that appear.

7. Click Save at the bottom of the page, and then click OK on the confirmation dialog box.

   The field is now locked and cannot be edited by updates to source records until the lock is removed. The link icon is also removed since a locked field cannot be linked to a source record field.

Unlocking an SBR Field

Once you unlock a field for overwrite in an SBR, the SBR is recalculated by the survivor calculator and the field can be updated by changes made to source records. The following figure shows an object profile in edit mode with all fields unlocked (as indicated by the column of icons below the red arrow).

Figure 41 Unlocked Fields in an SBR as Indicated by Closed Padlocks

To Unlock an SBR Field

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to unlock on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Scroll to the SBR field you want to unlock.

4. Click the unlocked padlock icon to the left of the field.

   ---

   Note –

   A closed padlock indicates an unlocked field that can be locked. An open padlock indicates a locked field that can be unlocked.

   ---

5. On both dialog boxes that appear, click OK.

6. Click Save at the bottom of the page, and then click OK on the confirmation dialog box.

   The field is now unlocked and can be edited by updates to source records. The link icon appears next to the field again because the field can now be linked to a source record field.

Overriding the Survivor Calculator's SBR

Linking an SBR field to a field in a source record is one way to ensure that the value for that field is not recalculated by the survivor calculator each time the object profile is updated. If you determine that a value in a specific source system is the most accurate data and should always be used in the SBR, you can link the field values and override the survivor calculator's version of the SBR. If you unlink a linked field, the value of that field is automatically recalculated by the survivor calculator as soon as the unlink action is performed. You can only link field values from the parent object.

Linking an SBR Field to a Specific Source Record

When you link a field in an SBR to a field in one of the profile's source records, the value of the field will always equal the value of the field in the source record, even when the source record field is updated. Linking a field in the SBR to a source record removes the survivor calculator from the update process for that field. Any updates made to or by other source records in the profile will not update the linked field in the SBR. Use linking when you have very high confidence that the field value from a specific source record is likely to be the most accurate and current value. You cannot link an SBR field if it is locked for editing.

The following figure shows two linked fields in an object profile, as indicated by the link icons to the left of the fields in the source record. All other fields have the link icon in the SBR.

Figure 42 Linked Fields in an SBR

To Link an SBR Field to a Source Record Field

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to link on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Scroll to the SBR field you want to link.

4. Click the chain–link icon to the far left of the field.

   A popup window appears where you can specify the source record to link.

5. On the popup window, select the source system code and the local ID of the source record to which you want to link the selected field.

6. Click OK on the dialog boxes that appear.

7. Click Save at the bottom of the page, and then click OK on the confirmation dialog box.

   The link icon moves from the SBR field to the source record field, and the lock icon is removed (because a field cannot be both linked and locked). The SBR field is now linked and can only be edited by updates to the source record to which it is linked.

Unlinking an SBR Field From a Source Record

Once you unlink a field a field in the SBR from the corresponding field in the source record, the SBR is recalculated by the survivor calculator and the field can be updated by changes made to other source records. The following figure shows an SBR with no fields linked, as indicated by all of the link icons next to the SBR fields (in the column beneath the red arrow).

Figure 43 Unlinked Fields in an SBR

To Unlink an SBR Field From a Source Record

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to link on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Scroll to the field you want to unlink.

4. Click the chain–link icon to the left of the field in the source object.

5. Click OK on both dialog boxes that appear.

6. Click Save at the bottom of the page, and then click OK on the confirmation dialog box that appears.

   The icon is moved from the source record field to the SBR field that is no longer linked. The SBR is recalculated by the survivor calculator.

Adding a Source Record to an Object Profile

If an object has local IDs in addition to those already recorded in the master index application, you can add the local IDs to the object’s profile by adding a source record to the profile. To add a local ID to an object profile, you need to specify information such as the system that assigned the local ID, certain parent object information, and the local ID itself. When you add a source record to an object profile, the survivor calculator determines what changes, if any, should be made to the SBR.

You cannot add a new local ID and system pair to an object profile if that same local ID and system pair already exists in another object profile.

Figure 44 Record Details Page – Add Parent Information

To Add a Source Record to an Object Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. At the bottom of the page, click Add SO.

   A new column appears to the right of the existing records for you to add the new source record.

4. Enter the system and local ID for the new source record, and then click Validate.

   If no existing record match the system and local ID you entered and the local ID is of a valid format, a message appears letting you know validation succeeded.

5. Enter information in the parent object fields.

6. For each child object to add, do the following:

   1. Click Add child_type in the column containing the new source record.

      For example, to add an address record, select Add Addresses.

   2. Enter the new information for the child object.

   3. Beneath the child object you updated, click Save child_type.

7. Scroll to the bottom of the column and click Save.

8. Click OK on the dialog box that appears.

   The page refreshes and the SBR is recalculated based on the new information.

   ---

   Note –

   You only need to enter required fields in order to save the new source record. Required fields are indicated by an asterisk (*).

   ---

Deactivating a Profile or Source Record

If an object profile or source record is no longer active, you cannot delete the profile or record, but you can deactivate it. Once you deactivate a record, you can reactivate it if needed. Deactivating an object profile removes the potential duplicate listings for that profile. If you deactivate a source record, the survivor calculator determines what changes, if any, should be made to the SBR.

Deactivating an Object Profile

Deactivated profiles cannot be modified, and in some cases, cannot be viewed. If you deactivate a profile in error, you can reactivate it if needed.

Figure 45 Record Details Page - Deactivate

To Deactivate an Object Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to deactivate on the Record Details page.

2. At the bottom of the page, click Deactivate.

   The profile is deactivated in the database and the EUID appears in beige on the MIDM.

Deactivating a Source Record

If an existing local ID for an object becomes obsolete, you can deactivate the source record with that local ID for the object profile. An object profile must have at least one active local ID; if you deactivate an object’s last active source record, the entire profile is deactivated. When you deactivate a source record from an object profile, the survivor calculator determines what changes, if any, should be made to the SBR.

You can deactivate a source record from the Record Details page, where you can view the source record within the context of its profile.

To Deactivate a Source Record (by EUID)

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the source record you want to deactivate on the Record Details page.

2. At the bottom of the page, click Edit.

3. Below the source record you want to deactivate, click Deactivate.

4. Click OK on the information dialog box that appears.

   The page refreshes and the SBR for the object profile containing the source record is recalculated based on the new information.

Reactivating a Profile or Source Record

Once an object profile or source record is deactivated, you can reactivate it if needed. Reactivating a profile causes the potential duplicates for the profile to be recalculated. Reactivating a source record causes the SBR to be recalculated.

Reactivating an Object Profile

If an object profile is deactivated in error or becomes active again, you can reactivate that profile. Reactivating a profile returns the profile to its status just prior to when it was deactivated.

Figure 46 Record Details Page - Reactivate

To Reactivate an Object Profile

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to reactivate on the Record Details page.

2. At the bottom of the page, click Activate.

3. Click OK on the information dialog box that appears.

   The profile is reactivated in the database.

Reactivating a Source Record

If a source record was deactivated in error or is no longer inactive, you can easily reactivate the source record. You can activate the source record from the Record Details page, where you can view the source record within the context of its profile.

To Reactivate a Source Record (by EUID)

1. Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the source record you want to deactivate on the Record Details page.

2. At the bottom of the page, click Edit EUID.

3. Below the source record you want to deactivate, click Activate.

4. Click OK on the information dialog box that appears.

   The page refreshes and the SBR for the object profile containing the source record is recalculated based on the new information.

Working with Potential Duplicate Profiles on the MIDM

The Duplicate Records function of the MIDM allows you to view any object profiles that are marked as potential duplicates of each other by the master index application. You can search for and view potential duplicate profiles on the MIDM, and then fix the potential duplication by either merging or resolving the two profiles. You can view potential duplicates that are resolved, but not those that are merged.

Perform any of the following tasks to monitor and fix potential duplicate profiles.

• Finding Potential Duplicate Profiles on the MIDM

• Merging Potential Duplicate Profiles

• Resolving Potential Duplicate Profiles on the MIDM

Finding Potential Duplicate Profiles on the MIDM

Potential duplicate profiles are determined based on the matching probability weight that indicates how closely two profiles match. You can easily find and compare potential duplicate profiles using the MIDM Duplicate Record function.

Figure 47 Potential Duplicate Comparison Page

To Find Potential Duplicates

1. Obtain information about the object whose potential duplicates you want to view, such as a system in which they are registered or the login ID of the user who created the object profile.

2. In the MIDM tabbed headings, click Duplicate Records.

   The Duplicate Records basic search page appears.

   Figure 48 Duplicate Records Basic Search Page

   
   

3. Do one of the following:

   1. To search by date range only, enter the date range in the basic search fields and then click Search.

   2. To use additional criteria for the search, select Advanced Search from the Search Type field, enter your search criteria, and then click Search.

      For more information about advanced search fields, see About Duplicate Records Search Fields on the MIDM.

      The Duplicate Records results list appears with key information for each potential duplicate record displayed.

4. In the results list, compare the displayed information to determine whether you want to view a detailed comparison of the potential duplicate profiles.

   Figure 49 Potential Duplicate Search Results List

   
   

5. To view a detailed comparison for a set of potential duplicate profiles, click the Preview button to the right of the profiles.

   ---

   Tip –

   The Preview button is the blue chevron button to the right of the potential duplicate profiles.

   ---

6. To view the source records associated with any of the displayed profiles, click View Sources beneath that profile. To return to the duplicate record comparison view, click View Sources again.

7. To view a transaction history for a displayed profile, click View History beneath that profile. To return to the comparison page, click View History again.

8. To mark a profile as not being a duplicate of the main profile, see Resolving Potential Duplicate Profiles on the MIDM.

9. To merge two or more profiles, see Merging Potential Duplicate Profiles.

10. To start a new search for potential duplicate records, click Advanced Search at the top of the page.

About Duplicate Records Search Fields on the MIDM

The fields located on the Duplicate Records search page allow you to specify information about the potential duplicate profiles you want to view.

Merging Potential Duplicate Profiles

When you compare potential duplicate profiles, you might find that the object profiles represent the same entity, or that a source record from one profile actually belongs in the other profile. You can perform either an object profile merge or a source record merge to correct this. When you merge profiles, the SBR of the surviving profile is automatically recalculated based on the source records involved in the merge. You can combine up to four profiles.

This topic only describes object profile merges. For more information about merging object profiles, see Combining Object Information on the MIDM. To learn how to merge source records, see Merging Source Records on the MIDM.

To Combine Duplicate Profiles From the Comparison Page

1. Perform a search for potential duplicates on the Duplicate Records page, as described in Finding Potential Duplicate Profiles on the MIDM.

2. To view a detailed comparison for a set of potential duplicate profiles, click the Preview button to the left of the profiles.

   ---

   Tip –

   The Preview button is the blue chevron button to the left of the potential duplicate profiles.

   ---

3. On the Duplicate Records comparison page, determine which of the displayed profiles you want to keep and then click the EUID of that profile.

4. Click the EUIDs of any other associated profile you want to merge into the profile you selected above.

   Each profile changes color to indicate it is selected.

   Figure 50 Duplicate Records – Selecting Profiles to Merge

   
   

5. Under the far right column, click Preview.

   The merge preview profile appears, allowing you to view the profile as it will appear after the merge.

   Figure 51 Duplicate Records – Merge Preview Profile

   
   

6. Compare the field values in the profiles to be merged to determine which values to populate into the kept profile. Click any values you want to keep.

   ---

   Note –

   Selecting a value to keep in the merge result profile creates a link from the SBR to the source record field that populated the field. For example, if the first name field from Record A is populated from Source Record 1, and you merge Record A into Record B and select the first name value from Record A, alink is created from the first name field in the resulting SBR to the first name field in Source Record 1. For more information on linking SBR fields to source record fields, see Overriding the Survivor Calculator's SBR.

   ---

7. Review the merge preview profile, and then click Merge to finalize the merge.

8. On the confirmation dialog box that appears, click OK.

   The surviving profile appears.

9. Review the surviving object profile to determine whether any source records need to be merged or deactivated.

Resolving Potential Duplicate Profiles on the MIDM

When you compare two potential duplicate profiles and determine that they do not represent the same object, you can resolve the two profiles to flag the profiles as not being potential duplicates. There are two types of resolution. Resolve removes a potential duplicate flag, but if one of the resolved profiles is updated the records might be listed as potential duplicates again. Resolve Permanently flags the two profiles as being permanently resolved regardless of whether one of the resolved profiles is updated.

To Resolve Potential Duplicate Profiles From the Results List

If the fields on the Duplicate Records search results list are sufficient to determine that two profiles do not represent the same object, you can resolve the profiles from the search results list.

1. Perform a search for potential duplicates on the Duplicate Records page, as described in Finding Potential Duplicate Profiles on the MIDM, and display the results list.

   The results list displays key identification fields that might provide enough information for you to determine whether the profiles should be resolved.

   Figure 52 Duplicate Records Search Result Entry

   
   

2. Scroll through the results until you see the profiles you want to resolve.

3. Beneath the duplicate profile you want to resolve from the Main EUID (the profile in the far left column), click Different Records.

   ---

   Tip –

   The Different Records icon is the brown icon beneath each profile.

   ---

4. On the confirmation dialog box that appears, do one of the following:

   • To flag the potential duplicate profiles as resolved but still allow the potential duplicate listing to be reinstated in the future, select Resolve Until Recalculation.

   • To flag the potential duplicate profiles as resolved and never allow the potential duplicate listing to be reinstated, click Resolve Permanently.

5. On the confirmation dialog box, click OK.

   The status of the potential duplicate entry is changed to Resolved and the profiles are no longer regarded as potential duplicates of one another.

6. Repeat this for each duplicate profile you want to resolve from the main profile.

7. If you resolve a profile in error, click Potential Duplicate beneath that profile in the results list to mark it as a potential duplicate again.

To Resolve Potential Duplicate Profiles From the Comparison Page

If you need to view detailed information about two profiles to determine whether they are a match, view them on the Duplicate Records comparison screen before you resolve them.

1. Display a set of potential duplicates on the Duplicate Records comparison page, as described in Finding Potential Duplicate Profiles on the MIDM.

   Figure 53 Duplicate Records Comparison Page

   
   

2. Beneath the duplicate profile you want to resolve from the Main EUID (the profile in the far left column), click Different Records.

   A confirmation dialog box appears.

3. On the confirmation dialog box that appears, do one of the following:

   • To flag the potential duplicate profiles as resolved but still allow the potential duplicate listing to be reinstated in the future, select Resolve Until Recalculation.

   • To flag the potential duplicate profiles as resolved and never allow the potential duplicate listing to be reinstated, click Resolve Permanently.

4. On the confirmation dialog box, click OK.

   The status of the potential duplicate entry is changed to Resolved and the profiles are no longer regarded as possible duplicates of one another.

5. Repeat this for each duplicate profile you want to resolve from the main profile.

6. If you resolve a profile in error, click Potential Duplicate beneath that profile in the results list to mark it as a potential duplicate again.

Unresolving Potential Duplicate Profiles on the MIDM

If two profiles were resolved and flagged as not being potential duplicates in error, you can undo the resolve transaction and mark them as potential duplicates once more. You can perform this from either the results list or the comparison page.

To Unresolve Potential Duplicate Profiles From the Results List

If the fields on the Duplicate Records search results list are sufficient to determine that a resolve transaction was performed in error, you can unresolve the profiles in the search results list.

1. Perform a search for potential duplicates on the Duplicate Records page, as described in Finding Potential Duplicate Profiles on the MIDM, and display the results list.

   The results list displays key identification fields that might provide enough information for you to determine whether the profiles should be unresolved.

   Figure 54 Duplicate Records Search Result Entry

   
   

2. Scroll through the results until you see the profiles you want to unresolve.

3. Beneath the duplicate profile you want to mark as a potential duplicate with the Main EUID (the profile in the far left column), click Potential Duplicate.

   The status of the potential duplicate entry is changed from Resolved and the profiles are once again regarded as potential duplicates of one another.

To Unresolve Potential Duplicate Profiles From the Comparison Page

If you need to view detailed information about two profiles to determine whether they should be unresolved, view them on the Duplicate Records comparison screen.

1. Display a set of potential duplicates on the Duplicate Records comparison page, as described in Finding Potential Duplicate Profiles on the MIDM.

2. Beneath the duplicate profile you want to mark as a potential duplicate with the Main EUID (the profile in the far left column), click Potential Duplicate.

   Figure 55 Unresolving Potential Duplicate Records

   
   

3. On the confirmation dialog box, click OK.

   The status of the potential duplicate entry is changed from Resolved and the profiles are once again regarded as possible duplicates of one another.

Working with Assumed Matches on the MIDM

The Assumed Matches function of the MIDM allows you to view any object profiles that were automatically updated by the master index application as a result of an assumed match. You can reverse the assumed match if necessary. The following topics provide instructions for finding profiles updated by an assumed match and then reversing the update if necessary. Perform the following tasks to work with profiles that were automatically matched.

• Finding Assumed Matches on the MIDM

• Reversing an Assumed Match on the MIDM

Finding Assumed Matches on the MIDM

You can find object profiles that were updated by an assumed match using the Assumed Matches function of the MIDM. When you search for assumed matches, you can select an object profile to view from a results list to determine whether the assumed match was made correctly.

To Find Assumed Matches

1. Obtain information about the object profile you want to view, such as their EUID, a system in which they are registered, or the login ID of the user who added the record that caused the update.

2. In the tabbed headings, select Assumed Matches.

   The Assumed Matches search page appears.

   Figure 56 Assumed Matches Search Page

   
   

3. On the Assumed Matches search page, enter the search criteria (for more information, see About Assumed Matches Search Fields).

4. Click Search.

   The Assumed Match Result page appears (for more information, see About Assumed Match Results Fields on the MIDM).

   Figure 57 Assumed Matches Search Results List

   
   

5. In the Results list, click the EUID of the assumed match profile you want to view.

   The Assumed Matches page appears with the assumed match profile displayed.

   Figure 58 Assumed Matches Comparison Page

   
   

6. To view a transaction history of the profile, click View History at the bottom of the page.

7. To undo the assumed match transaction, follow the instructions provided under Reversing an Assumed Match on the MIDM.

About Assumed Matches Search Fields

The fields located on the Assumed Matches search page allow you to specify information about the assumed match profiles you want to view.

About Assumed Match Results Fields on the MIDM

The fields located in the assumed match results list help you to identify an assumed match transaction to display on the Assumed Matches comparison page. The fields described in the following table always appear in the results list, but the list can be configured to include additional fields.

Reversing an Assumed Match on the MIDM

If you find that an assumed match was made in error, you can reverse the assumed match. This process returns the updated object profile to its status just prior to the assumed match update, creates a new object profile for the record that caused the assumed match, and recalculates the SBR for the existing profile.

Figure 59 Assumed Matches Page – Reversing an Assumed Match

To Reverse an Assumed Match

1. View the assumed match profile, as described in Finding Assumed Matches on the MIDM.

2. At the bottom of the page, click Undo Match.

   A confirmation dialog box appears, providing the EUID number of the new profile that will be created as a result of reversing the match.

3. On the confirmation dialog box, click OK.

   The assumed match is reversed, the updated profile is returned to its state prior to the assumed match, and a new object profile is created for the source record that caused the assumed match. Any changes that were made after the assumed match but before reversing the assumed match are retained.

4. On the information dialog box, click OK to view the newly created profile.

Combining Object Information on the MIDM

When you determine that two or more profiles represent the same object, you can merge the profiles to form one profile that contains the object’s most current information. You can also merge source records within one profile or from one profile to another. The resulting profile of a profile level merge is called the Merge Result Record. The SBR for the surviving profile is automatically recalculated based on the source records involved in the merge. In a source record merge, the SBRs for all affected profiles are automatically recalculated based on the resulting source records in each profile.

You can display the object profiles to merge using the Search function or the Duplicate Records function. This section describes how to merge records using the Search function. For information about merging records using the Duplicate Records function, see Merging Potential Duplicate Profiles.

You can merge profiles from either the Duplicate Records page or the Record Details page. The following topics provide instructions for merging profiles or source records from the Record Details or Source Record page. For information about merging profiles from the Duplicate Records page, see Merging Potential Duplicate Profiles.

• Merging Object Profiles on the MIDM

• Merging Source Records on the MIDM

Merging Object Profiles on the MIDM

When you merge object profiles, all of the source records associated with the non-surviving object profiles are transferred to the surviving object profile. The non-surviving profiles are given a status of merged and are no longer active. The SBR of the surviving profile is recalculated based on the new source records that were added to the profile due to the merge. After merging profiles, review the source records in the active profile to determine whether any of them should be deactivated or merged.

Use caution when merging more than two object profiles, as the entire merge process cannot be reversed.

To Merge Object Profiles

1. Perform a search for the object profiles you want to merge using any of the search procedures described in Searching for Object Profiles on the MIDM.

2. In the results list, select the check boxes to the left of the profiles you want to merge.

   You can select from two to four profiles.

3. Click Compare.

   The Comparison page appears.

   Figure 60 Comparison Page - Merging Object Profiles

   
   

4. Determine which of the displayed profiles you want to keep, and then click the EUID of that profile.

5. Determine which of the displayed profiles you want to merge into the profile you just selected, and then click their EUIDs.

6. Click Preview.

   The merge preview profile appears so you can review the results of the merge before finalizing it.

   Figure 61 Comparison Page - Merge Preview

   
   

   ---

   Caution –

   If you merge more than two profiles together, you can only unmerge the last two profiles that are merged (as determined by the master index application). Before proceeding, make sure that the profiles should be merged.

   ---

7. Compare the highlighted field values to determine which to keep in the final profile. Select each value you want to keep in the merge preview profile.

   ---

   Note –

   Selecting a value to keep in the merge result profile creates a link from the SBR to the source record field that populated the field. For example, if the first name field from Record A is populated from Source Record 1, and you merge Record A into Record B and select the first name value from Record A, a link is created from the first name field in the resulting SBR to the first name field in Source Record 1. For more information on linking SBR fields to source record fields, see Overriding the Survivor Calculator's SBR.

   ---

8. Click Merge.

9. Click OK on the confirmation dialog box that appears.

10. Review the surviving profile of the merge to be sure no source records need to be deactivated or merged.

Merging Source Records on the MIDM

You can merge source records from one object profile into a source record from another object profile or you can merge source records within one profile, as long as both source records originated from the same system. You can also specify which, if any, information to save from the non-surviving source record. When you merge source records, the non-surviving source record is transferred into the object profile of the surviving source record and is given a status of merged. The SBRs of the surviving profiles are automatically recalculated.

To Merge Source Records

1. In the tabbed headings, select Source Record.

2. Click the Merge sub-tab.

3. In the Source Record search fields select the source system for the records, enter two local IDs for the source records you want to merge, and then click View Records.

   The source record comparison page appears.

   Figure 62 Source Record Page– Merging Source Records

   
   

4. Determine which source records you want to merge, and click their local IDs.

   ---

   Tip –

   To learn more about the source records by examining the profiles to which they belong, click View EUID under the record you want to view. Once you are done viewing the profile, click Back to return to the Source Record page.

   ---

5. Click Keep LID#, where # is the heading number of the source record you want to retain after the merge.

   The merge preview record appears.

   Figure 63 Source Record Page – Merge Preview Record

   
   

6. Compare the highlighted fields in the source records to determine which value you want to keep. Click a highlighted value to add it to the merge preview record.

7. At the bottom of the page, click OK.

8. On the confirmation dialog box that appears, click OK.

   After you merge two source records, the surviving source record is updated, and the non-surviving source records are transferred to the “merge to” profile and is marked as merged. The SBRs for the object profiles involved in the merge are recalculated. If a “merge from” profile no longer has any source records, it is deactivated.

Unmerging Object Information on the MIDM

The following topics provide instructions for unmerging profiles and source records.

• Unmerging Object Profiles on the MIDM

• Unmerging Source Records on the MIDM

Unmerging Object Profiles on the MIDM

If object profiles are merged in error, the profiles can easily be separated by unmerging the profiles. When you unmerge object profiles, the information is returned to the original profiles, the source records are returned to their original profiles, and any changes that were made after the merge are retained. Any source records that were added while the profiles were merged are associated with the profile that was active at the time. After you unmerge object profiles, verify that the source records were distributed correctly in the resulting records.

To Unmerge Object Profiles

1. In the MIDM tabbed headings, click Transactions.

2. Perform a search for the object profiles to unmerge.

   For information about the search fields on this page, see About Transaction History Search Fields on the MIDM.

3. Select a transaction to unmerge from the search results list.

   ---

   Note –

   This must be an EUID merge transaction.

   ---

   Figure 64 Unmerge Page

   
   

4. Review the two displayed profiles to verify they should be unmerged.

   ---

   Caution –

   If you are unmerging profiles that were merged in a transaction that included three or four profiles, only the last two profiles merged will be unmerged. The remaining profiles cannot be unmerged.

   ---

5. At the bottom of the page, click Preview Unmerge.

   A preview of the unmerged record appears.

6. Verify the preview, and then click Unmerge.

7. On the confirmation dialog that appears, click OK.

Unmerging Source Records on the MIDM

If two source records are merged in error, the records can easily be separated by unmerging the two source records. When source records are unmerged, the source record that became inactive is reactivated and, if the source record was merged from a different object profile, it is returned to its original profile. The SBR is recalculated for all affected object profiles. Any changes made to the surviving source record following the merge are retained after the unmerge transaction.

To Unmerge Two Merged Source Records

1. Perform a search for the transaction to unmerge.

   For information about the search fields on this page, see About Transaction History Search Fields on the MIDM.

2. Select a transaction to unmerge from the search results list.

   ---

   Note –

   This must be a system object merge transaction.

   ---

   Figure 65 Unmerge Page

   
   

3. Review the displayed system records and profiles to verify the system records should be unmerged.

   ---

   Caution –

   If you are unmerging system records that were merged in a transaction that included three or four records, only the last two system records that were merged will be unmerged. The remaining records cannot be unmerged.

   ---

4. At the bottom of the page, click Preview Unmerge.

   A preview of the unmerged record appears.

5. Verify the preview, and then click Unmerge.

   ---

   Tip –

   To preview the source records involved in the transaction, click View Sources beneath the SBRs you want to view.

   ---

6. On the confirmation dialog that appears, click OK.

Learning About MIDM Reports

Sun Master Index provides a set of production and activity reports that can be generated from the MIDM. The production reports provide information about the current state of the data in the master index application, helping you monitor stored data and determine how that data needs to be updated. This information also helps verify that the matching logic and weight thresholds are defined correctly. Activity reports provide statistical information for transactions over specific periods of time.

The following topics provide additional information to help you understand and work with the default reports:

• MIDM Production Reports

• MIDM Activity Reports

• Configuring MIDM Reports

• Masked Data and MIDM Reports

MIDM Production Reports

Production reports provide information about the transactions that are processed through the master index database. These reports provide lists of potential duplicate profiles, merge transactions, unmerge transactions, assumed matches, updates, and deactivated profiles for a specified time period. These reports provide valuable information about how data is being processed with the current configuration. In addition to running the production reports daily, you should run them against any data that has been loaded from existing systems into the master index database in batch format. Production reports are run based on a date range you specify.

• Assumed Match Report - This report displays information about any profiles that were automatically updated by incoming data during the specified time period. The information in this report, in combination with data from the potential duplicate report, helps you determine whether the matching threshold for assumed matches is accurate. You should review this report daily to ensure that no assumed matches were made in error.

• Deactivated Record Report - This report displays a list of all profiles that were deactivated during the specified time period. Review this report daily to ensure that no profiles were deactivated in error. Master Index applications provide the ability to reactivate any deactivated profile.

• Potential Duplicate Report - This report displays information about object profiles that were marked as potential duplicates of one another during the specified time period. The information provided in this report can help you determine whether the matching threshold and the duplicate threshold are configured accurately. Review this report daily to ensure potential duplicates are managed in a timely manner, and use this report as a work list when processing potential duplicates.

• Merge Transaction Report - This report displays a list of all object profiles that were merged during the specified time period. Review this report daily to ensure that no profiles were merged in error. Master Index applications provide the ability to unmerge any merged profiles.

• UnMerge Transaction Report - This report displays a list of all object profiles that were unmerged during the specified time period.

• Update Report - This report displays object profiles whose information was updated during the specified time period. Review this report daily to verify the updates made in a given day. This report can help explain why a resolved potential duplicate listing was reinstated to the potential duplicate list.

MIDM Activity Reports

Activity reports should be run weekly, monthly, and yearly to obtain statistical data about the transactions that are processed through the master index database. These reports give the number of each type of transaction performed for the specified week, month, or year. They also provide cumulative information for the week, month, or year to date. The information you find in these reports helps analyze the condition of the data by giving you the number of potential duplicates created, the number of assumed matches, and so on.

• Weekly Activity Report - This report displays a summary of transactions that occurred against the database on each day for the specified calendar week (always Sunday through Saturday). The information provided in this summary includes the number of each of the following transactions performed each day.

  • Add

  • EUID Deactivate

  • EUID Merge

  • EUID Unmerge

  • LID Merge

  • LID Unmerge

  • Unresolved Potential Duplicates

  • Resolved Duplicates

  Monthly Activity Report - This report displays a summary of transactions that occurred against the database during the specified month. You can run this report for any calendar month. The information provided in this report includes a summary of each transaction listed for the weekly activity report above.

  Yearly Activity Report - This report displays a summary of transactions that occurred against the database for the specified calendar year. You can run this report for any calendar year. The information provided in this report includes a summary of each transaction listed for the weekly activity report above.

Configuring MIDM Reports

The report files are configured in midm.xml in the master index project. For detailed information and instructions on configuring the reports, see Configuring the Master Index MIDM Pages in Configuring Sun Master Indexes and Master Index Data Manager Configuration in Understanding Sun Master Index Configuration Options .

Masked Data and MIDM Reports

Though the MIDM can be configured to hide certain fields from users who do not have the appropriate security permissions, reports generated from the MIDM will display the hidden data if those fields are configured to appear on the reports. Be sure to only give access to users who should be able to view this information, or do not include hidden fields in the reports.

Running MIDM Reports

Reports are run from the Reports page of the MIDM. You need the appropriate security permissions to run the production and activity reports from the MIDM. Production and activity reports require that a time period be defined in the search criteria, and certain reports take additional search criteria.

To Run Reports From the MIDM

1. In the MIDM tabbed headings, click the Reports tab.

   The Reports Search page appears.

   Figure 66 Reports Search Fields

   
   

2. On the Reports Search page, select the type of report to run from Reports sub-tabs.

3. Enter the search criteria (for more information, see About Report Search Fields on the MIDM).

4. Click Search.

   The selected report appears, as shown in the following figure .

   Figure 67 Potential Duplicate Report Sample

   
   

5. To sort the report by a single column, click that column name.

6. To change whether the column is sorted by ascending or descending order, click again on the column.

7. To print the report, click Print in the upper right portion of the window.

About Report Search Fields on the MIDM

The report search fields let you specify a date range for each report. For Potential Duplicate reports, you can also specify the status of the potential duplicates returned by the search.