Revisioning contact information in policies
In policies, some contact data is revisioned. All revisioned contact information is effective dated based on the edit effective date of a particular policy transaction. This revisioning behavior is the same as for all other revisioned policy data. Revisioned contact fields are accurate as of a particular point in time.
In policies, PolicyCenter revisions pieces of contact information for certain contact roles. Because certain pieces of contact information are part of the policy contract, PolicyCenter must store that information on the bound submission exactly as it was at the time of binding. Each bound policy or completed policy transaction is a separate revision. Thus, a change to contact or contact role information has no impact on bound policies or completed policy transactions. This behavior is similar to how PolicyCenter revisions all other information about the policy. For example, when binding a submission, the name of the insured was Maria Smith. The name of the insured on the bound submission or issued policy, remains Maria Smith even if she subsequently changes her name to Maria Jones.
Information associated with contacts that is not part of the policy contract does not need to be revisioned. For example, the phone number for a billing contact three years ago is not part of the policy contract. You always want to see the most current phone number and do not care about past phone numbers.
For policy contacts, you define on a field by field basis for each role whether to revision basic contact information or account level role-specific information. Role-specific information on the policy level is by definition revisioned because everything at the policy level is by definition revisioned.
Depending on how the effective date of the policy transaction relates to the last update time of the contact, updates to contact information within a policy transaction can:
- Be considered current.
- Be back-dated if the effective date of a policy transaction is earlier than the last update time the contact.
- Be future-dated if the effective date of a policy transaction is later than the current date.
PolicyCenter tracks the last update time of the contact so that the policy correctly represents the contact data.
See also
Contact revisioning when contacts are synchronized
When contacts are synchronized with the account, PolicyCenter:
- Copies contact information from the account at the start of the policy transaction.
- Copies a change to the policy contact back to the account contact throughout the steps the policy transaction.
- Copies a change to the account contact to the policy contact throughout the steps of the policy transaction.
In submission and issuance policy transactions, contacts are always synchronized with the account. In cancellation policy transactions, contacts are never synchronized with the account. Other policy transactions synchronize to the account if both of the following are true:
- The effective date of the policy transaction is not in the future
- At the beginning of the policy transaction, the last update time of the contact is earlier than or equal to the effective date of the policy transaction
If a policy is synchronized with the account, a change to contact and contact role information outside the policy impacts the following:
- Pending Policy Transactions – Changes are immediately apparent when viewing any pending policy transactions because those policy transactions always display the up-to-date information. This information comes from the associated account-level contact and role information.
- Quoted Policy Transactions – When you bind a quoted but not bound submission, the application verifies that the revisioned policy contact information matches the account contact information. The information will not match if someone made a change to the synchronized information on the account contact after the quote was made. An example of this is contact name. If the contacts do not match, you will see a validation error. PolicyCenter generates this validation error because the change could affect the forms generated at quote time. When you quote the policy again, the application synchronizes the contact.
- New Policy Transactions – When new policy transactions on existing policies begin, the contacts on those policy transactions always reference the most recent contact and role information. It does not matter what contact and role the revision they are based on references.
Contact revisioning in future-dated changes
If the effective date of the policy transaction is in the future, changes to revisioned fields in contacts are handled as future-dated changes.
At the beginning of a future-dated change, PolicyCenter copies contact information from the account, so that the policy transaction starts out with the most up-to-date information. During the policy transaction, the account and policy contacts are not synchronized. The are not synchronized because changes to the contact are in the future and the account data must represent the current contact information. During the policy transaction, changes to the policy contact data create work items for the Apply Pending Account Data Updates work queue. In the default configuration, this work queue runs nightly. On the day that the change takes effect, the work queue updates the account contact. For more information, see Contact batch process.
Example of a future-dated change
On September 1, 2010, Jane Smith calls to say she is getting married on September 4, 2010 and will change her name to Jane Smith-Jones. The agent issues a future-dated policy change updating her marital status and name. PolicyCenter rates the policy again because of the marital status change.
Until September 4, the account contact remains Jane Smith, a single woman. On September 4, the Apply Pending Account Data Updates work queue updates the account contact to Jane Smith-Jones, a married woman.
Contact revisioning in back-dated changes
If the effective date of the policy transaction is earlier than the last update time of the contact, changes to revisioned fields in contacts are handled as back-dated changes.
When starting a back-dated policy change, PolicyCenter does not copy contact information from the account because this information is newer. That is, the last update time of the contact is more recent than the effective date of the policy change. So for earlier points in time, the based-on policy contact data is more accurate. During the policy transaction, the account and policy contacts are not synchronized. They are not synchronized because that might result in changing data at the account level that is more current than in the back dated change.
When contact information changes in a back-dated change, PolicyCenter creates an activity and note reminding the user about the change. The user can choose to apply the change manually. PolicyCenter does not apply the change automatically because PolicyCenter cannot assume that the change will always be applied.
Example of a back-dated change
This example makes further changes to Jane Smith-Jones’ policy. Previously, the agent made future-date changes to the policy in Contact revisioning in future-dated changes.
On September 10, 2010, Jane calls to report that since the beginning of the policy, her date of birth has been incorrectly entered as May 1, 1990. She was actually born in 1988. The agent issues a policy change that corrects the date of birth effective back to the beginning of her policy on July 1, 2010. This change is an out-of-sequence policy change. On the policy period from July1 through September 3, PolicyCenter updates Jane Smith’s date of birth to 1988. On the policy period from September 4 forward, PolicyCenter updates Jane Smith-Jones’ date of birth to 1988.
PolicyCenter does not update the account contact automatically in a back-dated change. PolicyCenter creates an activity and note describing the change to the contact. The user assigned to the activity decides whether to make that change, and updates the account contact directly. In the case of Jane’s date of birth, the user gets the activity. The user decides to update date of birth on the account contact because it is true throughout the life of the policy.
In some back-dated changes, the user does not want to update the account contact. Suppose on September 10, 2010, Jane calls to report that since the beginning of the policy her marital status has been incorrectly recorded as Single. She was married previously, and her correct status is Separated. In the policy, the agent issues a policy change that corrects the marital status effective back to the beginning of her policy on July 1, 2010. This change is an out-of-sequence policy change. On the policy period from July1 through September 3, the last update date on the marital status field is July 1. Therefore, PolicyCenter updates Jane Smith’s marital status to Separated on this policy period. On the policy period from September 4 forward, the last update date on the marital status is later than the effective date of the back-date change. Therefore, PolicyCenter does not change Jane Smith-Jones’ marital status of Married on this policy period. PolicyCenter creates an activity and note describing the change of marital status. In the case of Jane’s marital status, the user gets the activity and decides not to update the marital status on the account contact.