Understanding Policies and Trigger Points

Policies are the result of combining trigger points, conditions, and defined actions to complete a desired business request. The framework includes components for building policies.

Application developers and functional business analysts use a wizard-like interface to build, manage, and associate trigger points with policies. Business analysts can create interactive policies that react to customer behavior of particular interest to them. For example:

  • If a banking customer deposits more than ten thousand dollars, a banking analyst can create a regulatory IRS notification.

  • If a high-value customer has logged three or more critical support issues with a call center within a week, a business executive could send a letter of apology.

Policies supplement, but do not alter, normal transactional processing. Therefore, a policy cannot be used to stop a particular behavior due to some specified restriction. If the condition portion of a policy evaluates to true, the policy causes an action to be performed. If the specified condition evaluates to false, then no consequential actions occur. Policies are evaluated independently from each other. Therefore, if more than one policy is to be evaluated at the same time, the consequential actions of one policy cannot alter or influence the actions of another. Likewise, the sequence of policy execution cannot affect the results of another policy.

You construct a policy by defining one or more conditions, specifying one or more actions, and associating them with a trigger point. A policy cannot be activated without defining at least one condition and action. You can reuse defined policies with multiple trigger points if the elements of the policy agree with the contexts of the trigger points.

Trigger points are events from which the analytic decision engine is invoked by the application. The framework supports the registration of new trigger points, when needed. Examples of trigger points are:

  • When a customer is identified.

  • When a product is selected.

  • After you sign in to a self-service application.

Registration of a trigger point involves specifying:

  • The type of actions to be invoked.

  • The context in which the associated policies are to be carried out.

During runtime, policies are triggered by specific trigger points within application components, resulting in defined actions being taken.

Note: Registration of a trigger point also involves introducing necessary code in the application to request the decision engine to evaluate the policies pertaining to a trigger point.