Configuring policy holds
Policy hold object model
Policy holds are a type of underwriting issue.
The following illustration shows some of the objects related to policy hold.
The PolicyHold entity is the main
entity for policy holds. This entity has an array to access PolicyHoldZone entities which
describe the regions for which the hold applies. This entity also has
an array to access PolicyHoldRule
entities which describe the rules for the hold. The rule entity specifies
the line of business, job (policy transaction) type, date type, and coverages
for which this rule applies.
The PolicyHoldJob entity keeps track of:
- Jobs that are currently under a policy hold.
- The last time PolicyCenter evaluated the job against the policy hold.
This entity has the following fields:
Job– A foreign key to the job.LastEvalTime– The last time that PolicyCenter evaluated this job against this policy hold.
When a policy hold applies, PolicyCenter creates an
underwriting issue of one of the policy hold types specified in the UWIssueType system table.
See also
Policy hold permissions
The following permissions relate to policy holds.
Permission |
Code |
Description |
|---|---|---|
Edit policy hold |
|
Permission to edit a policy hold. |
View policy hold |
|
Permission to access the Policy Holds screen. |
Create policy hold |
|
Permission to create a policy hold. |
In the sample data, the Underwriting Supervisor role has all the policy hold permissions. The Underwriter role has he View policy holds permission. For information about loading the sample data, see The PC Sample Data screen.
Policy hold authority grant
Authority profiles determine the types of underwriting issues that a user can approve. Authority profiles contain authority grants. The Regulatory Policy Hold and UW Policy Hold authority grants to allow users to approve those types of policy holds.
See also
Policy hold underwriting issue types
The UWIssueType
system table defines issue types for underwriting and regulatory policy
holds. You can view this table in Product Designer by navigating to System Tables
and selecting uw_issues_types.xml.
The following table lists some of the values in the UWIssueType system table for policy
hold underwriting issue types.
Code |
Name |
Blocking Point |
Checking Set |
|---|---|---|---|
|
|
|
|
|
|
|
|
PolicyCenter evaluates each checking set at specific blocking points for each job (policy transaction) type. Then PolicyCenter determines whether or not to raise an underwriting issue.
There are two checking sets for policy
holds: UWHold and RegulatoryHold. PolicyCenter evaluates
these checking sets at all blocking points. Therefore, PolicyCenter notifies
the user each time the job advances to the next step.
Blocking points in the UWIssueType system table represent
points in the job at which an issue can block progress of the job. The
underwriting hold blocks on bind, but regulatory hold blocks on quote.
The gw.job.JobProcessUWIssueEvaluator
class contains code that defines the blocking points at which to evaluate
the checking set.
See also
Policy hold Gosu classes
In the DefaultUnderwriterEvaluator
Gosu class, the policyHold
method evaluates whether to raise underwriting issues. This class is
in the gw.lob.common package.
This method checks to see if the checking set is either a regulatory hold or an underwriting hold. If so, the method retrieves all policy holds in the database, and compares each hold with the current policy period. If the details of the policy period match a hold, then the method raises an underwriting issue. The underwriting issue has the Code, Description, and Long Description of the policy hold.
The policyHold
method also adds or updates the PolicyHoldJob
element in HeldJobs array
for this job (policy transaction) and policy hold. The method also updates
the LastEvalTime field
of that PolicyHoldJob
to indicate the last time that PolicyCenter evaluated this hold against
the job.
The policy hold batch process deletes
the entry in the HeldJobs
array that corresponds to this job and policy hold when the hold no longer
applies to this job.
The code that compares the policy period with the hold is in the gw.job.uw.PolicyHoldEnhancement class. This enhancement contains methods that compares dates, locations, and coverages of the given policy period.
Policy Hold batch process
The Policy Hold Job Evaluation batch process reevaluates all open policy transactions under a policy hold. If the policy hold conditions no longer apply, the batch process removes the policy hold from the policy transaction. PolicyCenter returns the renewal to automated processing except in the following cases:
- If a renewal has been escalated to manual processing, then PolicyCenter will not return the renewal policy transaction to automated processing. This behavior applies even if the policy is set to Allow issuance when hold released. For example, if a user approved or rejected a policy hold underwriting issue, then PolicyCenter will not return the renewal policy transaction to automated processing.
- If the policy transaction has not been escalated to manual processing but has , the batch process sends the producer an activity reminder. The activity reminds the producer to retry quoting or binding the job.
In the default configuration, the Policy Hold Job Evaluation batch process runs nightly. You can also manually start the batch process from the Batch Process Info screen.
The code for this batch process is PolicyHoldJobEval. The batch process
calls the IPolicyHoldJobEvalPlugin.
Policy Hold Job Evaluation plugin
The batch process calls the following
methods in the policy hold job evaluation plugin (IPolicyHoldJobEvalPlugin):
findJobsToEvaluate– Finds jobs that PolicyCenter needs to evaluate against the policy holds blocking the jobs. In the default configuration, this method finds jobs that are:- Open.
- Have a policy period with an active blocking policy hold.
- Has not been evaluated since the last time the policy hold has changed.
evaluate– Determines if the policy hold was deleted or whether the policy hold still applies.
See also
