Choosing the renewal flow type

PolicyCenter provides multiple renewal flows from which you can choose. Use only one of these renewal flows. The following table compares and contrasts the different renewal flows, with the first column containing the general name for this renewal flow.

Renewal flow	How PolicyCenter renews a policy	If the insured pays	If the insured does not pay
Bind and cancel	In the typical case, renewal occurs without user intervention. First, PolicyCenter quotes the renewal. Next, PolicyCenter sets the job workflow status to `Renewing`. The workflow behavior after this status change is configurable, based on how close the current date is to the effective date of the renewal. If the renewal effective date is sufficiently in the future, the workflow waits. After a configurable date, such as 30 days before the renewal effective date, the workflow automatically issues the renewal. On issuance of the policy renewal: PolicyCenter sends charges to BillingCenter. The `PolicyTerm.Bound` property becomes `true`. Before PolicyCenter automatically sets the workflow status to `Renewing`, you can manually make this change in the user interface. Within the policy renewal job, click Edit, make changes, click Bind Options, and then click Renew. The job workflow status becomes `Renewing`. Before PolicyCenter automatically issues the policy, you can manually make this change in the user interface. Within the policy renewal job, click Edit, make changes, click Issue Now. The renewal immediately issues.	By this time, the policy is already issued. No special action happens.	By this time, the policy is already issued. If you use BillingCenter, and BillingCenter does not receive a payment, BillingCenter instructs PolicyCenter to perform a “cancel for non-payment”. The delinquency plan determines whether BillingCenter specifies a flat cancel or midterm cancel. After BillingCenter requests cancellation of the policy, any money received after any cancellation remains in the account unapplied fund.
Renewal offer	In the typical case, renewal occurs without user intervention. First, PolicyCenter quotes the renewal. Next, PolicyCenter sets the job workflow status to `Renewing`, which is a waiting state. When the job workflow status changes to `Renewing`, you must configure your `Event Fired` rules to send an offer to the insured: The base configuration does not provide an integration to send an offer to the insured. You can decide whether to provide the insured with a single payment plan or multiple options. To get the payment plans, configure PolicyCenter to request this information from the billing system. Include any payment plan information on a renewal offer letter. The offer must contain a reference number to identify this job. Use the renewal job ID as the PolicyCenter offer identifier. In some cases, the automatic renewal does not reach the `Renewing` status, for example, if the policy had approval problems. In the policy renewal job, click Quote. The renewal offer status changes to `Renewing`. This status change causes your `Event Fired` rules to send the offer letter to the insured. At this point, the property `PolicyTerm.Bound` is `false`.	The billing system sends PolicyCenter notice of payment by using the PolicyCenter PolicyRenewalAPI web service method notifyPaymentReceivedForRenewalOffer. If you use BillingCenter, this happens because BillingCenter registers the payment including the offer reference number. BillingCenter holds the payment as a suspense payment with an associated offer reference number. A suspense payment is a payment not yet matched to an account and a policy. BillingCenter then calls the PolicyCenter PolicyRenewalAPI web service as mentioned earlier. The PolicyCenter PolicyRenewalAPI web service binds the policy. Binding the policy sets the `PolicyTerm.Bound` property to `true`.	If the workflow status is `Renewing`, the job waits for the insured to respond to the offer. If the insured did not respond by the renewal deadline, the workflow job status changes to Not Taken (`NotTaken`) status. If the workflow status changed to Not Taken and money arrives afterward, the billing system tells PolicyCenter about the payment received. PolicyCenter does not accept this request. Instead, PolicyCenter returns an error to the billing system that the renewal is incapable of renewal. If you use BillingCenter, BillingCenter creates an activity for someone to look into the new payment that it cannot apply.
Confirmed renewal	The confirmed renewals flow can be summarized as follows: PolicyCenter binds and issues the renewal. PolicyCenter waits for confirmation from the insured that the insured wants the policy. PolicyCenter sets the property `PolicyTerm.Bound` to `false` until receiving sufficient payment.	After receiving sufficient payment for the renewal, the billing system notifies PolicyCenter. For example, the billing system calls the PolicyCenter PolicyRenewalAPI web service method confirmTerm. The confirmTerm method performs the following actions: PolicyCenter sets `Policy.PolicyTerm.Bound` to `true`. PolicyCenter sends a message to the billing system to confirm the renewal.	Eventually, the billing system notifies PolicyCenter of a Not Taken cancellation. All Not Taken cancellations are flat cancellations.

Renewal flow

How PolicyCenter renews a policy

If the insured pays

If the insured does not pay

Bind and cancel

In the typical case, renewal occurs without user intervention. First, PolicyCenter quotes the renewal. Next, PolicyCenter sets the job workflow status to Renewing. The workflow behavior after this status change is configurable, based on how close the current date is to the effective date of the renewal. If the renewal effective date is sufficiently in the future, the workflow waits. After a configurable date, such as 30 days before the renewal effective date, the workflow automatically issues the renewal.

On issuance of the policy renewal:

PolicyCenter sends charges to BillingCenter.
The PolicyTerm.Bound property becomes true.

Before PolicyCenter automatically sets the workflow status to Renewing, you can manually make this change in the user interface. Within the policy renewal job, click Edit, make changes, click Bind Options, and then click Renew. The job workflow status becomes Renewing.

Before PolicyCenter automatically issues the policy, you can manually make this change in the user interface. Within the policy renewal job, click Edit, make changes, click Issue Now. The renewal immediately issues.

By this time, the policy is already issued. No special action happens.

By this time, the policy is already issued.

If you use BillingCenter, and BillingCenter does not receive a payment, BillingCenter instructs PolicyCenter to perform a “cancel for non-payment”. The delinquency plan determines whether BillingCenter specifies a flat cancel or midterm cancel.

After BillingCenter requests cancellation of the policy, any money received after any cancellation remains in the account unapplied fund.

Renewal offer

In the typical case, renewal occurs without user intervention. First, PolicyCenter quotes the renewal. Next, PolicyCenter sets the job workflow status to Renewing, which is a waiting state.

When the job workflow status changes to Renewing, you must configure your Event Fired rules to send an offer to the insured:

The base configuration does not provide an integration to send an offer to the insured. You can decide whether to provide the insured with a single payment plan or multiple options. To get the payment plans, configure PolicyCenter to request this information from the billing system. Include any payment plan information on a renewal offer letter.
The offer must contain a reference number to identify this job. Use the renewal job ID as the PolicyCenter offer identifier.

In some cases, the automatic renewal does not reach the Renewing status, for example, if the policy had approval problems. In the policy renewal job, click Quote. The renewal offer status changes to Renewing. This status change causes your Event Fired rules to send the offer letter to the insured.

At this point, the property PolicyTerm.Bound is false.

The billing system sends PolicyCenter notice of payment by using the PolicyCenter PolicyRenewalAPI web service method notifyPaymentReceivedForRenewalOffer.

If you use BillingCenter, this happens because BillingCenter registers the payment including the offer reference number. BillingCenter holds the payment as a suspense payment with an associated offer reference number. A suspense payment is a payment not yet matched to an account and a policy. BillingCenter then calls the PolicyCenter PolicyRenewalAPI web service as mentioned earlier.

The PolicyCenter PolicyRenewalAPI web service binds the policy. Binding the policy sets the PolicyTerm.Bound property to true.

If the workflow status is Renewing, the job waits for the insured to respond to the offer.

If the insured did not respond by the renewal deadline, the workflow job status changes to Not Taken (NotTaken) status.

If the workflow status changed to Not Taken and money arrives afterward, the billing system tells PolicyCenter about the payment received. PolicyCenter does not accept this request. Instead, PolicyCenter returns an error to the billing system that the renewal is incapable of renewal. If you use BillingCenter, BillingCenter creates an activity for someone to look into the new payment that it cannot apply.

Confirmed renewal

The confirmed renewals flow can be summarized as follows:

PolicyCenter binds and issues the renewal.
PolicyCenter waits for confirmation from the insured that the insured wants the policy. PolicyCenter sets the property PolicyTerm.Bound to false until receiving sufficient payment.

After receiving sufficient payment for the renewal, the billing system notifies PolicyCenter. For example, the billing system calls the PolicyCenter PolicyRenewalAPI web service method confirmTerm.

The confirmTerm method performs the following actions:

PolicyCenter sets Policy.PolicyTerm.Bound to true.
PolicyCenter sends a message to the billing system to confirm the renewal.

Eventually, the billing system notifies PolicyCenter of a Not Taken cancellation. All Not Taken cancellations are flat cancellations.

The following table lists how to configure each type of renewal flow.

Renewal flow	Configuration overview	More information
Bind and cancel	The policy renewal plugin (`PolicyRenewalPlugin`) has a method called `doesRenewalRequireConfirmation`, which takes a PolicyPeriod object. To require confirmation, your plugin implementation of that method must return `true`. Otherwise, return `false`.	Not taken renewals cancellation
Renewal offer	The policy renewal plugin method isRenewalOffered takes a PolicyPeriod object. To support renewal offers, your plugin implementation of that method must return `true`. Otherwise, return `false`.	Renewal offers flows Not taken renewals cancellation
Confirmed renewal	The policy renewal plugin method doesRenewalRequireConfirmation takes a PolicyPeriod object. To support confirmed renewal, your plugin implementation of that method must return `true`. Otherwise, return `false`.	Confirmed renewals flow Not taken renewals cancellation

Renewal flow

Configuration overview

More information

Bind and cancel

The policy renewal plugin (PolicyRenewalPlugin) has a method called doesRenewalRequireConfirmation, which takes a PolicyPeriod object. To require confirmation, your plugin implementation of that method must return true. Otherwise, return false.

Not taken renewals cancellation

Renewal offer

The policy renewal plugin method isRenewalOffered takes a PolicyPeriod object. To support renewal offers, your plugin implementation of that method must return true. Otherwise, return false.

Renewal offers flows

Not taken renewals cancellation

Confirmed renewal

The policy renewal plugin method doesRenewalRequireConfirmation takes a PolicyPeriod object. To support confirmed renewal, your plugin implementation of that method must return true. Otherwise, return false.

Confirmed renewals flow

Not taken renewals cancellation

If you want to choose different renewal flows for different renewal jobs, add your own logic for the plugin methods described in the previous table. For any renewal job, your policy renewal plugin logic must define exactly one renewal flow. For example, for one renewal job you cannot return true for both doesRenewalRequireConfirmation and isRenewalOffered.

In the base configuration, all lines of business use the bind-and-cancel flow.