Contact data model

A Contact is the Guidewire core application data model entity used in both client and vendor contact management. In the base configuration, this entity is the core application equivalent of the ContactManager entity ABContact, described previously in ABContact data model.

The Contact entity has an entity hierarchy and a set of relationships to other entities.

Contact entity hierarchy

The Contact entity has subtypes for various types of contacts, like Person, Company, and Place. In their base configurations, PolicyCenter and BillingCenter use just the Person and Company subtypes to link with ContactManager.

In ClaimCenter, these subtypes have additional subtypes, like Adjudicator, CompanyVendor, LegalVenue, and so on. The following figure shows the Contact entity hierarchy. This entity hierarchy has a parallel in the ABContact entity hierarchy in ContactManager. See ContactManager and core application contact entity hierarchies.

Note: The following diagram includes a special Contact subtype, UserContact. This entity is used by the User entity, which represents a user of the application. The User entity has a foreign key to UserContact to store data like the user’s address and phone number, which the application can display in its user interface. Additionally, the UserContact entity makes it possible to do things like proximity search to assign users to claims. UserContact entities are not intended to be used as either vendor contacts or client contacts, and they do not link to ContactManager.

The relationships between the Contact entity hierarchy and the Person, Place, and Company subtypes.

Contact entity relationships

The Contact entity is associated with other entities. A contact can have multiple addresses, related contacts, and tags. A Contact entity must have at least one tag. Except for the primary address, references to those entities are handled with arrays of join entities. For example, there is ContactAddress for addresses and ContactContact for related contacts, as shown in the following figure:

The relationships between the Contact, ContactAddress, ContactContact, ContactTag, and Address entities.

The physical location, the address, of a Contact is stored in the Address entity, which maintains the contact’s street or mailing address. A Contact can reference a primary address and, through the ContactAddress entity, other secondary addresses.

Contacts can have relationships with other contacts. For example, a Person might be employed by a particular Company. The ContactContact entity maintains data about the relationships a contact can have with other contacts.

Note: For simplicity, the diagram shows ContactContact connecting to a different instance of Contact. However, ContactContact can also point back to the original contact. For example, you can be your own primary contact.

Contacts can have tags, like Client and Vendor, and specialist services that the contact provides, like carpentry or independent appraisal. A Contact entity references its tags by using the ContactTag entity. The relationship between a contact and its services are maintained by ContactManager, which is why there is no property accessing services in the Contact entity relationship model.