Guidewire Renewal Process Made Easier

I have worked in the Guidewire space for the better part of 15 years, most of which has been supporting PolicyCenter. A number of those projects have similar modifications, this article covers one of them.

Renewals are a common transaction that requires attention to meet desired business requirements. As is said, OOTB code is an example and not a complete set of requirements, let alone multiple LOBs in multiple jurisdictions.

OOTB provides a flexible workflow letting you manipulate and extend it to meet various business scenarios. One great feature utilizes a system table called the Notification Config System Table. This table has multiple look-up indexes, including LOB and Jurisdictions, used to execute high-level processes in the workflow, such as when to start a non-renewal.

If you look in RenewalProcess, you will find property getters returning hardcoded wake-up dates like PendingRenewalFirstCheckDate and PendingRenewalFinalCheckDate. Depending on the line of business or jurisdiction, these values can change. You will also find similar methods using the Notification Config System Table to return values within this module. As good developers, we know to avoid hardcoding business values that are subject to change and, in this case, may vary by Jurisdiction and LOB. Instead, I suggest putting all hardcoded values into the Notification Config System Table directly under business control and not under developers’ control where bugs are born.

Below are step-by-step instructions to modify the RenewalProcess to move hardcoded data into the Notification Config System Table, letting this data be maintained directly in Product Designer with its own screen.

Step 1. Modify the NotificationCategory typelist to include the hardcoded value types in Renewal Process (PendingRenewalFirstCheckExt, PendingRenewalFinalCheckExt, IssueAutomatedRenewalExt, etc.). Do this for each date you need to calculate.

<typecode
    code="pendingnonrenewalfirstcheckExt"
    desc="Lead Time for the First Check for a non renewal"
    name="PendingNonRenewalFirstCheckExt"/>
<typecode
    code="pendingrenewalfinalcheckExt"
    desc="Lead Time for the Final Check for a renewal"
    name="PendingRenewalFinalCheckExt"/>
<typecode
    code="pendingnonrenewalfinalcheckExt"
    desc="Lead Time for the Final Check for a Non Renewal"
    name="PendingNonRenewalFinalCheckExt "/>

Step 2. Add a new method which accepts the Notification Category and returns the desired value.

private function getLeadTimeDate(notificationCategory : typekey.NotificationCategory) : int {
    var notificationPlugin = Plugins.get(INotificationPlugin)
    var lineToJurisdictions = _branch.AllPolicyLinePatternsAndJurisdictions
    return notificationPlugin.getMaximumLeadTime(_branch.PeriodEnd, lineToJurisdictions, notificationCategory)
}

Step 3. Amend the required, date-related property getters in RenewalProcess to call to this new method passing in the category.

protected property get PendingRenewalFirstCheckDate() : Date {
    var leadTime = getLeadTimeDate(NotificationCategory.TC_PENDINGRENEWALFIRSTCHECKEXT)
    return _branch.PeriodStart.addDays(-leadTime)
}

Step 4. Notification Config System Table.Within Product Designer, add entries for the new NotificationCategory categories based upon your current configuration.

<NotificationConfig public-id="kimputing:0000002">
    <ActionType/>
    <Category>pendingrenewalfirstcheckExt</Category>
    <EffectiveDate>2001-01-01 00:00:00.000</EffectiveDate>
    <ExpirationDate/>
    <Jurisdiction/>
    <LeadTime>80</LeadTime>
    <LineOfBusiness/>
    <PremiumIncreaseThreshold/>
    <RateIncreaseThreshold/>
</NotificationConfig>

Let’s summarize. The above simple modifications move hardcoded business data to a spot that allows businesses to manage the processes without additional coding.

Danual Lewis
VP of Professional Services

• GeekCorner