Adding a new checking set

The default configuration of PolicyCenter provides a number of predefined checking sets. Checking sets represents points in the job at which issues can be raised. PolicyCenter evaluates each checking set at specific blocking points for each job type and determines whether or not to raise an underwriting issue. For each checking set, you can modify when the checking set is evaluated. See Triggering point mapping.

However, you will need to add a new checking set if you have an underwriting rule that requires checking at a new combination of job type and blocking point.

The following table describes the checking set values in the base configuration.

Value	In UI?	Description
All		PolicyCenter checks this rule at all blocking points. PolicyCenter removes an existing underwriting issue if the evaluators do not trigger this type of issue. Issues created by this checking set may come from external systems in a way that is not necessarily synchronized with the job flow. For example, a claim system sends notice of excessive claims, or a billing system sends notice of a delinquent account. If you have an issue that cannot change once the policy is quoted (without re-editing the policy), do not use this checking set.
Manual	•	The underwriting issue is created when the user manually added an issue to the policy period. PolicyCenter displays Manual issues on the Risk Analysis screen.
MVR		For motor vehicle record underwriting issues. PolicyCenter checks for this issue at quote, quote release, bind, and issuance.
PolicyRenewalAPI	•	PolicyCenter checks this rule prior to calling policy renewal web services. Policy renewal web services provides methods for managing renewals in PolicyCenter.
PreBind	•	For underwriting issues that can only be detected immediately prior to binding the job. PolicyCenter checks this rule prior to binding.
PreIssuance	•	For underwriting issues that can be detected immediately prior to issuance. For submission policy transactions, PolicyCenter checks this rule prior to issuing the policy. If the policy transaction does not have an issuance step, PolicyCenter checks this rule prior to binding.
PreQuote	•	For underwriting issues that can be detected on the policy period even before quote, such as issues related to data entered in draft mode. PolicyCenter checks this rule prior to generating a quote.
PreRateRelease		PolicyCenter checks these rule underwriting rules after quoting and before the rate or quote is released.
PreQuoteRelease	•	For underwriting issues that need information from a valid quote or that can be detected after a valid quote. For example, use this checking set for issues that depend on the premium. PolicyCenter checks this rule after a valid quote, but before releasing the quote.
Question		For underwriting issues is based on answers to a question set. PolicyCenter checks this rule before quote.
Referral		For underwriting issues is related to underwriting referral reasons on the policy. PolicyCenter checks this rule at all blocking points. PolicyCenter displays these issues in the UW Referral Reasons tab of the Risk Analysis screen. You can also add a referral reason to a policy by using the `addReferralReason` API.
RegulatoryHold		For underwriting issues related to policy holds with the Regulatory Hold hold type. PolicyCenter checks this rule at all blocking points. The user is notified each time the job advances to the next step.
Reinsurance		For underwriting issues related to reinsurance. For example, you can use this checking set to raise an issue if a policy has insufficient reinsurance. PolicyCenter checks this rule at all blocking points except quote.
Renewal	•	For underwriting issues related to renewals. PolicyCenter checks this rule in renewal policy transactions at quote and issuance.
Upgrade		In certain cases, Guidewire uses this value when upgrading PolicyCenter. Do not use this value for any other purpose.
UWHold		Use for underwriting issues related to policy holds with the Underwriting Hold hold type. PolicyCenter checks this rule at all blocking points. Therefore, the user is notified each time the policy transaction advances to the next step.

The In UI column indicates the values that appear in the Rule screen of the base configuration. The TriggeringPointKey.TF_UWRULECHECKINGSETFILTER filter narrows the choices in the user interface. Modify this filter to add hidden values such a RegulatoryHold.

Except for All, a rule can be associated with only one checking set.

Checking set values correspond to the UWIssueType.CheckingSet property. The UWIssueCheckingSet typelist defines these values.

The blocking point at which each checking set is evaluated is specified in the JobProcessUWIssueEvaluator.gs class. The code specifies which checking sets are evaluated at all blocking points. For each blocking point, the code specifies which additional checking sets are evaluated. Each job type can also specify when checking sets are evaluated.

For more information about checking sets and blocking points, see: