Job interactions with underwriting issues
At specific places in the job flow, the job classes raise issues at checking sets and stop job progress because of blocking issues.
You can view and modify the Gosu code for each job. The Gosu code is in the
gw.job package in Studio.
The following topics provide the checking and blocking points for each job type for which underwriting is provided in the base configuration. Through configuration, you can extend underwriting to other job types, such as cancellations.
Submission
The SubmissionProcess class handles checking sets and blocking points at the following times:
Submission job |
Checking sets |
Blocking points |
|---|---|---|
Before quoting |
|
|
Before quote release |
|
|
During bind, when not issuing |
|
|
During bind, when also issuing |
|
|
Renewal
Unlike other jobs, the RenewalProcess is often automated. As a result, renewal follows a different flow than the other jobs. There are a few primary differences in the automated flow:
- Checks are done and then repeated at various timeout points in the process.
- Blocking issues generate exceptions. When this occurs, the renewal is escalated to the underwriter.
The renewal job handles checking sets and blocking points at the following times:
Renewal job |
Checking set |
Blocking point |
|---|---|---|
Before quoting |
|
|
Before quote release |
|
|
Before scheduling the first check |
|
|
During the first check |
|
|
During the final check |
|
|
Before issuing the renewal |
|
|
The code handles automated renewals differently from manual renewals. In automated renewals, all issues are run as auto-approvable. Issues are given automated approvals if the special renewal user has sufficient authority to progress the job. The runMethodAsRenewalUser method gets a user from the getAutomatedRenewalUser method in the IPolicyRenewalPlugin. In the default configuration, the user is renewal_daemon. The automated renewal runs the job as this user, using the authority profile of this user for approvals. This user approves the issues.
The runMethodAsRenewalUser method sets a flag on the RenewalProcess object indicating that the renewal is automated.
See also
- For more information about the
IPolicyRenewalPlugin, see Renewal plugin.
Policy Change
The PolicyChangeProcess class handles checking sets and blocking points at the following times:
Policy change Job |
Checking set |
Blocking point |
|---|---|---|
Before quoting |
|
|
Before quote release |
|
|
During bind |
|
|
The code handles automated policy changes differently from manual policy changes. In automated policy changes, all issues are run as auto-approvable. Issues are given automated approvals if the special policy change user has sufficient authority to progress the job. In the default configuration, the user is policychange_daemon. The automated policy changes runs the job as this user, using the authority profile of this user for approvals. This user approves the issues.
Rewrite
The RewriteProcess and RewriteNewAccountProcess classes
handle checking sets and blocking points at the following times:
Rewrite job |
Checking set |
Blocking point |
|---|---|---|
Before quoting |
|
|
Before quote release |
|
|
During bind |
|
|
Issuance
The IssuanceProcess class handles checking sets and blocking points at the following times:
Issuance job |
Checking sets |
Blocking points |
|---|---|---|
Before quoting |
|
|
Before quote release |
|
|
During bind, when also issuing |
|
|
Reinstatement
When you reinstate a canceled policy, approvals carry over from the canceled policy even if they were approved only until the next change. PolicyCenter does not consider reinstatement a change.
Cancellation
Cancellation jobs do no checks for underwriting issues.
Audit
Audit jobs do no checks for underwriting issues.