Pend Rules

Pend rules can pend a policy for manual review. When a policy is pended, the user needs to manually decide to accept the pend reasons i.e. to resolve them after modifying or without modifying the policy. The pend rule describes the circumstances in which a policy pends. The pend reason describes why the policy has pended. Each pend rule must specify a pend reason that will be attached to the policy should that rule trigger.

Pend rule configuration consists of three different types of fields: to identify the rule, to describe the circumstances under which a policy pends and to drive what happens when the policy actually pends.

Field	Description
Code	The identifying code of the pend rule
Description	The description of the pend rule
Source	The source of the policy: Integration Point, User Interface or Either
Message	If specified, one of the messages on the policy should match the message
Message Group	If specified, one of the messages on the policy should match one of the messages in the group
Brand	If specified, this brand should match the brand of the policy
Condition	The dynamic logic condition that is executed to determine if the policy must be pended
Pend Reason	The pend reason that is attached to the policy (see below)
Enabled?	Is the pend rule enabled?

Pend Reasons

As specified above, each pend rule must specify a pend reason that will be attached to the policy (describing why the policy has pended) should that rule trigger.

Field	Description
Code	The identifying code of the pend reason
Description	The description of the pend reason
Reattach?	Should the pend reason be reattached? (if unchecked, this reason will not be reattached, i.e., will not cause the policy to pend if the policy pend history shows that the same pend reason has been resolved in the past)