Renewal plugin

To customize how PolicyCenter handles renewals, implement IPolicyRenewalPlugin. For example, this plugin determines when to start a Renewal job for a PolicyPeriod. However, note that this plugin does not actually create the Renewal job itself. Instead, the work queue called PolicyRenewalStart actually starts the renewal job. A work queue is like a built-in batch process except that it automatically parallelizes the work across a PolicyCenter cluster. The renewal work queue looks for policy renewals to start.

The most important method in the IPolicyRenewalPlugin plugin interface is the shouldStartRenewal method. It determines whether to start the renewal job, as previously mentioned. Its only argument is a policy period and returns true if and only if the policy period is ready for a new renewal.

The built-in implementation evaluates the date that the renewal normally starts. To do this it calls another method on the plugin called getRenewalStartDate. If you write your own version of this plugin, refer to the built-in implementation and copy the code from the getRenewalStartDate method if appropriate.

If you write your own version of this plugin, refer to the built-in implementation class gw.plugin.job.impl.PolicyRenewalPlugin. Copy the getRenewalStartDate method as appropriate.

The plugin implemented in the base configuration performs the following operations.

  • If there are open conflicting jobs on the policy, it prevents renewal until the user handles these issues.
  • If there are no conflicting jobs, this method returns true if getRenewalStartDate() returns a date in the past.
  • If there are conflicting jobs, this method returns true if getRenewalStartDate() returns a date less than three days in the past.
  • All other cases return false.

Get renewal start date

The other method you must implement in this plugin is the getRenewalStartDate method. This method must determine the date on or after which to start a renewal job for a given PolicyPeriod. In contrast to the shouldStartRenewal method, the getRenewalStartDate method is primarily used for display purposes. It is also useful for testing purposes. Within this plugin, only the shouldStartRenewal method determines authoritatively whether the policy is ready for renewal.

The built-in implementation evaluates the given PolicyPeriod to determine the earliest date that PolicyCenter creates a renewal job for this policy period. This implementation gets a notification date for the PolicyPeriod from the currently-registered implementation of the INotificationPlugin. The built-in implementation then adds further lead time based on the product and period end date of the policy period. It always truncates the date to midnight on that date. In other words it removes the time-of-day part of that date. This happens because it forces any programmatic date comparison of the date that this plugin returns to always be a day (not time) comparison.

Note:

Changing the implementation of getRenewalStartDate does not reset the field PolicyTerm.NextRenewalCheckDate of existing policy terms. Therefore, run the Clear Policy Renewal Check Dates batch process if you modify the implementation of this method.

Get automated renewal user

Your plugin must be able to get the PolicyCenter user to associate the renewal policy period. Implement the getAutomatedRenewalUser method, which takes a PolicyPeriod and returns a User.

The built-in behavior finds and returns the PolicyCenter user with the credential renewal_daemon.

Determine whether to use renewal offers

Your plugin must be able to determine whether this is the kind of policy period appropriate for the PolicyCenter renewal offer flow. The built-in behavior checks if the current job type for this policy period is Renewal and also is a business auto product. You can customize this logic for each product to use all one flow, or a mix of flows depending on the product or other custom logic.