Changing the subtype of a Contact instance

Important considerations before changing a contact subtype

This feature must be used with caution by experienced database and configuration professionals who are familiar with the Contact data model. It applies only to ContactManager and ClaimCenter. To use this feature, you must log out of the application and set the application server run level to maintenance during the contact subtype change.

The change of subtype directly affects the database. It causes ContactManager to be unable to synchronize the contact with ClaimCenter until you make the same subtype change in both ClaimCenter and ContactManager. Additionally, fields can be deleted and array fields can cause user interface exceptions.

For example:

• A subtype change can delete fields that do not exist in the new subtype. If feasible, determine which fields will change and where you want to move data in the new subtype. Then make any data updates you can in ContactManager before changing the subtype. You might also want to save the original contact data until you can review the contact after the subtype change.
• Related contacts and other arrays are not deleted when you change a subtype. However, they can cause problems in the user interface.
• In ContactManager, you can delete problematic data for the contact, such as related contacts that are not compatible with the new subtype, before making the subtype change.

See also

• Contact subtype field differences and changing subtypes

Overview

In ClaimCenter and ContactManager, you can change the subtype of a contact that was created with the wrong subtype without having to delete and re-create the contact. For example, you created a contact with subtype Doctor when you intended the contact to be subtype Attorney. If it is possible to delete the contact and re-create it with the correct subtype, do so. However, deleting and re-creating the contact might not be practical if the contact has history, such as being the payee on a check.