Policy forms

For the insured customer, the physical representation of an insurance policy is a collection of policy forms. Policy forms define aspects of the policy such as coverages, exposures, exclusions, and government regulations.

Use policy forms for the information that comprises the policy contract. For generating and tracking information that is not part of the policy contract, use documents.

Overview

PolicyCenter supports viewing a list of forms in the user interface. You can also integrate with a forms printing system hosted separately from PolicyCenter. Although printing forms is primarily associated with issuance in a submission policy transaction, forms can be printed as part of any policy transaction. For example, a policy change might trigger reprinting a changed form, or printing additional forms that are now necessary because of newly-added vehicles or other changes.

Note: For what Guidewire calls policy forms, the insurance industry sometimes calls endorsements on a policy. Guidewire avoids the term endorsements due to its ambiguity in the industry, since endorsements sometimes refer to policy changes.

All PolicyCenter forms are automatically inferred forms, not manually added forms. In PolicyCenter, forms are not added explicitly by the user. Instead, PolicyCenter users add coverages, exclusions, and other policy data. Then PolicyCenter generates forms automatically by using forms inference logic and configuration settings. In addition, the form itself never contains variable information that is not already encoded in the data model or product model for that policy.

If a user submits a new auto policy, the forms to print when issuing the policy can be inferred by the coverages, vehicles, and other fields. If the insured later adds another vehicle to a policy, PolicyCenter determines which forms to reprint and whether to print entirely new forms for the new vehicle.

In the user interface, forms are listed on the Forms screen after the policy is quoted. The user interface displays a list of forms not the actual representation of the forms. After quoting, the list of forms is just a preview, not the final list of forms that will be attached to the policy. After the policy is bound (or after the policy is issued in a submission), the list of forms may be different. The list may be different because the information to accurately infer some forms is available only at binding or issuance. When the policy is bound or issued, your integration code sends XML data describing the form to an external system which prints the forms to paper or electronic format.

The forms feature of PolicyCenter has the following components:

What	Where to configure	Description
Forms basic definition	In PolicyCenter, go to Administration > Business Settings > Policy Form Patterns.	View or add policy form patterns that can be inferred for policies created in PolicyCenter.
Custom inference classes	Custom Gosu classes defined in Studio.	You can define custom inference classes to get more advanced behavior than is possible with the basic forms definitions. These custom classes define the conditions that determine when to add the form to the policy.
Forms preview	No configuration needed.	The job (policy transaction) wizard user interface displays a preview of the list of forms for the current policy.
Form printing integration	Event Fired rules. Custom messaging plugins.	Event Fired rules intercept forms issuance events and generate messages. Custom messaging plugins (destinations) that you register must send the XML payload to the forms printing system. Typically, this occurs only prior to binding a policy transaction.

If your forms printing system integrates with a document management system (DMS), the printing system can generate a visual representation of the form and add it to the DMS. After it does this, the integration code can also connect with PolicyCenter to let it know there is a new document associated with the policy. You can then view the policy from the Documents screen in the policy file.