General guidelines for extending contacts

With some restrictions, you can customize the contact entity hierarchy by adding subtypes or custom fields. You cannot make any of the following hierarchy modifications:

You cannot delete or move the root entity Contact.
You cannot delete or move the three subtypes Person, Company, and Place.
You cannot create a contact entity that is a peer to Contact.
You cannot create a contact entity that is a parent to Person, Company, or Place.

You can add a field to any of these entities. If you add a field to an entity that is higher in the hierarchy, all entities below it inherit the field. Before adding a field, ensure that the field makes sense for all the entity’s subtypes.

You can create a peer to Person, Company, or Place, and you can modify these three entities. A peer entity to one of these three entities is a subtype of Contact. You can also create a new subtype and modify the other subtypes.

If you have integrated your Guidewire core application with ContactManager, you typically extend both the core application and the ContactManager hierarchies to mirror each other. Most contacts require central management. If you have a contact subtype that does not require central management, you can create that type just in the Guidewire core application and not in ContactManager.

The Guidewire core applications provide the Gosu class ContactMapper that you use when extending the Contact data model for coordination with ContactManager. The corresponding class you use in ContactManager is gw.webservice.ab.ab1000.abcontactapi.ContactMapper. Each Guidewire core application also has a pair of XML configuration files for mapping contact names and typelists to and from ContactManager.

The matching and searching functions for contacts require each subtype to have a collection of fields that makes it unique.