Issue keys

The underwriting rule and issue key uniquely identify each underwriting issue. For any given combination of underwriting rule and issue key, there can be only one issue on a policy period at a given time. When creating an issue, any pre-existing issue with the given type and key will be returned, and any deactivated issue that matches will be activated and then returned.

On the underwriting issue, the UWIssue.IssueType property specifies the UWIssueType of the corresponding the underwriting rule. Issue key is specified in the UWIssue.IssueKey property. The PolicyEvalContext object automatically enforces this.

Guidewire recommends that you do not change the algorithm for forming the key for an issue after moving that algorithm to production. If you change the algorithm, current issues may be treated as orphaned. PolicyCenter will create new copies of the issues, requiring new approvals or rejections.

Issue Key Guidelines

Guidewire recommends these guidelines for forming issue keys.

For issues that affect the policy as a whole, such that there is only ever one such issue, use the code of the underwriting rule as the issue key. Total policy premium is an example of this. Thus, if the premium goes up or down, the same issues will be edited, rather than raising new issues each time.

For issues that relate to a particular entity, have the issue key encode the FixedID of the entity, or potentially some other unique identifier such as the VIN number. For example, use this method for an issue relating to the collision deductible on a given vehicle. This method allows that same issue to be raised for several different vehicles. It also ensures that the same issue will be modified if changes affect that issue.

If the issue relates to a jurisdiction, create one issue for each jurisdiction, with the jurisdiction encoded as part of the issue key. Since approvals for jurisdiction-based issues only apply to one jurisdiction at a time, rather than to a set of jurisdictions, each jurisdiction must have its own issue. An issue relating to a different jurisdiction would not reuse approvals or rejections. For example, an issue around the garage jurisdiction of a vehicle encodes both the FixedID or VIN of the vehicle as well as the jurisdiction. Changing the garage jurisdiction generates a new issue, rather than modifies the existing issue. This behavior also applies to set comparator types that you develop.

If the issue relates to a specific location, or a specific building at a certain location, encode the FixedID or other invariant identifier into the issue key. This encoding ensures that approving Building 2 in San Francisco to go without an alarm does not approve the same for Building 2 in Los Angeles.