Contact object model

PolicyCenter stores information about the contact on the account level and the policy level. For information on the Contact data model, see Contact data model.

The contact object model is designed to handle contact revisioning. The following illustration shows some the relationships of the Contact entity, using personal auto as an example. Other lines of business have the same basic entity structure with their own PolicyLine subtype and fields.

The Contact entity has a number of subtypes including Person and Company. The diagram shows some of the fields for a Person. The Contact entity has FirstName and LastName fields from its subtype Person entity.

Some of the entities inside the PolicyPeriod Entities box have revisioned fields. These revisioned fields are marked rev’d. These fields are revisioned as described in Revisioning contact information in policies. Revisioned fields implement the account syncable interface. For more information, see Account synchronization classes for contacts.

See also

Linked addresses object model

The following illustration shows some of the entities associated with contacts and linked addresses.



The LinkedAddress entity contains an array of linked addresses.

When you link an address to another address, PolicyCenter takes one of the following actions:

  • If the other address is not already linked, PolicyCenter creates a new LinkedAddress.
  • If the other address is already linked, PolicyCenter adds the address to the existing LinkedAddress.

You can link to an address on an AccountContact that has the role NamedInsured or AccountHolder. You can also link to an address on a contact that is the PrimaryNamedInsured on the PolicyPeriod.

See also

Contact roles for accounts and policies

The PolicyCenter base application has contact roles defined at the account and policy levels. These roles are subtypes of the AccountContactRole and PolicyContactRole entities. The AccountContactRole entity represents a contact filling a role on the account, such as Maria Smith as a driver on the account. The PolicyContactRole represents a contact filling a role on the policy, such as Maria Smith as the primary named insured on the policy.

The following table lists the contact roles at the account level and the corresponding roles at the policy level.

AccountContactRole subtype

PolicyContactRole subtype

AccountHolder

AccountingContact

SecondaryContact

ClaimsInfoContact

InspectionContact

AccountingContact

NamedInsured

PolicyNamedInsured

Driver

PolicyDriver

BillingContact

PolicyBillingContact

AdditionalInsured

PolicyAddlInsured

AdditionalInterest

PolicyAddlInterest

SuppliedEmployee

PolicySuppliedEmployee

ReceivedEmployee

PolicyReceivedEmployee

MiscContact

PolicyMiscContact

WCPolicyContactRole

OwnerOfficer

   PolicyOwnerOfficer (subtype of WCPolicyContactRole)

   WCLaborContact (subtype of WCPolicyContactRole)

LaborClient

      PolicyLaborClient (subtype of WCLaborContact)

LaborContractor

      PolicyLaborContactor (subtype of WCLaborContact)

The roles in the first column are subtypes of AccountContactRole which can be added to the account level. If there is no corresponding role in the PolicyContactRole column, the account contact role can only be associated with a contact added to the account. These roles represent people or company contacts with roles associated with the account but not with individual policies.

In some cases, a policy contact role is associated with an account level contact role, such as PolicyDriver and Driver. A policy contact role can be added to any of the policies within that account. (Many roles only apply to certain lines of business.) A contact role can contain fields that are shared across policies and other fields that are different across policies.