Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Explaining hit policies

Objective

After completing this lesson, you will be able to describe hit policies

Hit policies

Hit policies are used to define how the decision table manages inputs that match several rules, or alternatively, inputs that do not match any rules.

There are two main types of hit policies. The first is the single hit policy. With this policy, only one rule can fire, and the final result of the decision is one output value.

The second is the multiple hit policy. With this policy, rules can fire without an explicit order. Multiple hit tables either return set of values or aggregate the final result of the decisions.

Single hit policy - unique

There is a third hit policy - the unique hit policy. When the unique hit policy is used, only one rule is allowed to fire for any combination of inputs. All inputs are assumed to be independently partitioned from each other, i.e. that any combination is actually possible. Overlapping rules are not allowed.

A decision table with a unique hit policy, as described in the preceding text.

Note

U = unique hit policy

A '-' stands for wild card, which matches any value.

Take a look at the rules:

In rule two: if the chosen type of delivery is Express delivery, the Type of customer is a Retailer, and Kind of goods is the wild card, it doesn't matter whether the kind of goods are Groceries or Material goods, any value is fine. The output of the rule will always be High shipping priority.
In rule three: if the Chosen type of delivery is Standard delivery, the Kind of goods are Groceries, and the type of customer is a Wholesaler, then the priority of shipment is High.

Single hit policy - first

When the first policy is used, rules might overlap, but only one rule fires. The first hit policy assumes an ordering of the rules - they are evaluated from top to bottom. As soon as one rule fires, the output of that rules is the result of the decision. Once one rule fires, no other rule is checked.

A decision table showing the first hit policy, as described in the text.

In this example the first rule to be checked by the decision table is whether the Chosen type of delivery is Express delivery and whether the customer is a Wholesaler. If so, this rule fires. If not, the second rule is checked. If the second rule doesn't match the input values, the third rule is checked and so on.

Note that the last rule in the table serves as a 'catch all rule'. This means that when none of the previous rules match the input values, this rule will fire.

Catch all rules

The ordering of rules and the use of catch all rules should be treated with great caution. Take a look the following example: due to the ordering of rules, each Private customer will receive a discount of 10%, no matter what his Purchase value is (due to the wild card). This is because this rule is the first rule to be checked by decision table, and the first hit policy employs and ordering of rules therefore this decision table doesn't make such sense.

Decision table, as described in the preceding text.

Single hit policy - any

By using the any hit policy, multiple rules cover the same combination of input values. However, this overlap is only allowed if the overlapping rules have the same output.

When the combination of input values are associated with Not an active contract, Annual charge is not paid but the Minimum turnover is reached, then the first two rules fire. They both generate the same output, the VIP requirements are unfulfilled.

Sample decision table, as described in the preceding text.

Single hit policy - priority

Several rules can match for a given input when the priority hit policy is used. The outputs are ordered according to priority. The output with the highest priority is returned (for example the highest discount wins).

Decision table with a callout in the Outputs column: This is the ordered ranking of the output values. Low has the highest priority, followed by Medium and High.

In the above example, when the Age is 70, and the Medical history is Bad, then both rules three and four apply. The priority policy makes sure that only output Medium is returned, because Medium appears in the output list before High, and therefore has a higher priority.

Multiple hit policy - collect

Let's assume that a purchase order is accepted when:

A valid quotation number is referenced;
The pricing matches the quote;
All required items are included in the order;
The quotation has not expired.

If all conditions are met, then the purchase order is acceptable. If at least one condition is not met, the purchase order is not acceptable.

The three following decision tables are constructed with different hit policies, that's why they look different. Nevertheless, the tables implement the same decision logic and therefore will yield the same result for any given input data.

Screenshot of three decision tables, each with a different hit policy, as explained in the preceding text.

Multiple hit policy - collect

The multi-hit policy allows that multiple rules can fire without an explicit order. DMN's default is to provide the set of output values between brackets as the result. In this way, when multiple rules fire, the output is a list of values.

On the other hand, if multiple rules fire and the output is aggregated, the result will be one output value. This aggregation is completed by a function on the output values:

Sum - returns the sum of the distinct outputs.
Min - returns the smallest output value.
Max - returns the largest output values.
Count - returns the number of distinct outputs.

Multi-hit policies are best used for score cards that accumulate for matching units. For instance, the condition of an inspected item might be based on multiple checks with accumulated points for various defects.

Example multiple hit policy

Take a look at the following example

The total amount of vacation days in an organization depends on the sum of two input values -- the employee's age and their number of years of service.

Every employee has 20 standard vacation days, no matter his age or years of service;
If the age of the employee is above 55, they will get five extra days;
After eight years of service, the employee will get five extra vacation days;
A final extra five days are added if the employee has 20 years of service.

To build the scorecard, the first thing to do is to select the multiple hit policy Collect. The aggregation function is Sum, because the total amount of vacation days is added up.

In the Decision Table Configuration dialog, Collect (multiple) is selected as the Hit Policy. Sum is selected as the Aggregation.

If the employee is 20 years old and has only been with the company for one year they will only get 20 standard vacation days.

A 30 year old employee who has been with the company for nine years, will get 20 standard days + an extra five days because they have more than eight years of service.

If the employee is 60 years old and has been with the company for 32 years they will get 20 standard days + five days because they are over 55 years old + five days because they have more than 8 years of service + another five days because they have more than 20 years of service. This makes a total of 35 vacation days.

Sample decision tree showing the Age and Years of service inputs, as discussed in the preceding text.

Next lesson