Configuring custom form inference

A custom form inference class is a subclass of gw.forms.FormData that does not implement the GenericFormInference interface. You cannot associate a form with a custom form inference class in the Policy Form Patterns screen. Instead, you must modify the custom_form_inference.xml system table in Product Designer. Each row in the table corresponds to a particular form pattern code. Multiple rows in the table can reference the same custom inference class for different form pattern codes.

You can edit rows in the custom_form_inference table.

For each row in the table, you must enter:

Field

Description

FormCode

The code for the FormPattern. Enter the same value into the Code field on the Basics tab of the policy form screen.

InferenceClass

Enter the fully-qualified name of the inference class.

For all form patterns listed in the custom_form_inference table, PolicyCenter uses the custom inference class. If this table does not list a form pattern, PolicyCenter uses the generic inference class specified in the GenericInferenceClass field of the FormPattern.

Custom inference class

A custom form inference class is a subclass of the FormData abstract class that links to each form. For example, abstract class WCFormData extends FormData and provides some helper methods which Workers’ Compensation uses. In turn, the Form_WC_00_06_03_CT class extends WCFormData. In the custom_form_inference table in Studio, the definition of form WC_00_06_03_CT sets gw.lob.wc.forms.Form_WC_00_06_03_CT as the class to use in processing the form logic for that particular form.

Multiple form patterns can share an inference class if appropriate.

The FormData class is an abstract class that provides common functionality such as populating the FormDescription field on Form. By default, PolicyCenter uses the description of the pattern. It also contains methods for populating additional fields on the form. If you extend FormData class, then you must implement the following abstract methods in your subclass:

  • populateInferenceData
  • InferredByCurrentData
  • addDataForComparisonOrExport

The FormData class contains a default implementation of getLookupDate which uses the reference date of the current policy transaction as the lookup date for determining which form patterns are available. In the case of forms directly related to a coverage, condition, or exclusion, you can override the getLookupDate method. The override uses the reference date of that coverage, condition, or exclusion to determine form pattern availability. The reference date of the coverage, condition, or exclusion is potentially different than the reference date of the current policy transaction.

If PolicyCenter finds that a form is available in at least one jurisdiction by using the lookup date returned by getLookupDate, it then calls its populateInferenceData method. Input parameters to this method are the inference context object and the set of available jurisdictions. Typically, the populateInferenceData method looks through the policy data and collects the information relevant to that form. If getLookupDate is overridden, then getLookupDate will likely perform that work and populateInferenceData may do nothing.

After PolicyCenter populates the data, the inference engine invokes the InferredByCurrentData property on the form. This property determines whether the form is part of the policy based on the current state of the data. However, even if the method returns true, it does not mean that PolicyCenter expects the issuance system to issue the form. The field values on the form pattern and the data for comparison or export must still be considered.

For example, consider a form pattern that you do not want added again mid-term if its data changes. PolicyCenter issues the form only if the form does not already exist on the policy within the current policy term. Or, consider a form pattern that you want added again when its data changes mid-term. PolicyCenter issues the form only if the form would contain changed data compared to the last time it was added to the policy. As such, returning true from InferredByCurrentData indicates that the policy data on the policy transaction satisfies the conditions for including the form on the policy. This method does not take into account the policy lifecycle or previously issued forms.

Note: See Forms inference and integration for more information on forms inference.