ContactManager and core application contact entity hierarchies

The Guidewire core application data models and the ContactManager data model both group and classify contact data as hierarchies. By default, ContactManager provides a contact entity hierarchy that supports both the Client Data Management add-on module and ClaimCenter vendor data management. Additionally, ContactManager entities have the prefix AB (for Address Book).

PolicyCenter and BillingCenter use only part of the hierarchy for client data management: Contact, Person, Company, and UserContact.

ClaimCenter uses the entire hierarchy. In the default application, all the ClaimCenter contact types but UserContact appear in ContactManager with AB prefixes. The following table shows the ClaimCenter hierarchy and the supporting hierarchy in ContactManager supplied in the base products:

ClaimCenter	ContactManager
Contact	ABContact
Person	ABPerson
Adjudicator	ABAdjudicator
PersonVendor	ABPersonVendor
Attorney	ABAttorney
Doctor	ABDoctor
UserContact
Company	ABCompany
CompanyVendor	ABCompanyVendor
AutoRepairShop	ABAutoRepairShop
AutoTowingAgcy	ABAutoTowingAgcy
LawFirm	ABLawFirm
MedicalCareOrg	ABMedicalCareOrg
Place	ABPlace
LegalVenue	ABLegalVenue

Each core application Contact entity and subentity has a corresponding ABContact entity or subentity in ContactManager, with the exception of UserContact.

Note: While there is an ABUserContact entity in the ABContact hierarchy, this entity is not used, even for ContactManager users. UserContact is used both in core applications and ContactManager solely to provide address and other contact information for a User. A core application UserContact does not link to ContactManager. UserContact is never used for vendor or client information.

When ContactManager creates a contact, an instance of an ABContact entity or subentity, ContactManager also creates a unique identifier for that instance. This unique identifier is used both by core applications and by ContactManager to ensure that each application is referencing the same contact. In the core applications, AddressBookUID is the field used to uniquely identify a contact that is stored in ContactManager. In ContactManager, the corresponding field is LinkID.

For a contact stored both in ContactManager and in a core application, ContactManager sends the unique identifier in the LinkID field to each core application that uses the contact. The core application stores this unique identifier in the AddressBookUID field of the contact. If a contact in a core application has a non-null value in its AddressBookUID field, that value means that the contact is stored in ContactManager. Otherwise, the AddressBookUID field is null, meaning that the contact is stored only locally in the core application, and not in ContactManager.

To enable all applications to reference the same contact, you must not change an AddressBookUID or a LinkID field.

Guidewire designed the data models to enable the Guidewire core applications and ContactManager to be compatible. If you make a contact-related extension to a Guidewire core application’s data model, you typically extend the ContactManager data model as well to reflect the change. You must extend both applications if you want contact information that is captured, stored, and used in one application to be available to the other. If you have more than one core application installed, you might have to make the same extension in your other core applications as well.

Mapping of entities between applications ensures that contact records are stored with the correct entity in both the Guidewire core application and ContactManager. Mapping is not the same as linking contacts or synchronizing them, which determines if the records are the same between the two applications. Linking and synchronizing are separate operations from mapping.