Best Practices Modeling Choosing the DMN hit policy

Version: 8.5

Choosing the DMN hit policy

Hit policies describe different ways (standardized by DMN) to evaluate the rules contained in a
decision table. Different hit policies do not only lead to different results, but typically also require
different modes of thinking and reason about the meaning of the entire table. Therefore, it's
crucial to not just know the different DMN hit policies, but also to understand the motivations for
their existence and the most typical cases for using them.

Knowing the DMN hit policy basics

A decision table consists of several rules, typically represented as rows. When reading such a
row, we look at certain input values and deduct a certain result represented by output values.
When using the simplest hit policy "unique" (U), such rules do not overlap: only a single rule
must match.

Jacket
Hit Policy:Unique 3 3

When Then Annotations

Season 1 Jacket 2
1 2
string string

1 "Spring" "Blazer" "A light blazer should actually do it."

2 "Summer" "Rain Jacket" "It might rain, so better take one with you."

3 "Fall" "Leather "Best season to use the best one."

Jacket"

4 "Winter" "Down "Keeps you warm even in northern germany."

Jacket"

Jacket
Hit Policy:Unique 3

Ask AI
 When Then Annotations
Season 1 Jacket 2
string string

1 "Spring" "Blazer" "A light blazer should actually do it."

2 "Summer" "Rain Jacket" "It might rain, so better take one with you."

3 "Fall" "Leather Jacket" "Best season to use the best one."

4 "Winter" "Down Jacket" "Keeps you warm even in northern germany."

1 We define an "input" value season here. For every single season ...
2 ... there is a jacket defined we want to use, the "output" of the rules here.
3 The hit policy "Unique" (indicated by the character U) enforces that rules do not overlap:
only a single rule must match.
Now consider that we build a decision table with overlapping rules. In other words, that means
more than one rule may match a given set of input values. We then need one of the alternative
hit policy indicators to unambiguously understand the decision logic according to which such
rules are interpreted.

The hit policy indicator is a single character shown in the decision table's top left cell, right
beneath the decision's name. The character is the initial letter of one of the defined seven hit
policies U nique, A ny, P riority, F irst, C ollect, O utput order and R ule order. Furthermore, the
hit policy 'Collect' may also be used with one of four aggregation operators, actually giving us
four more hit policies C+ (Sum), C< (Minimum), C< (Maximum) and C# (Number).

Eight of those eleven hit policies evaluate a decision table to a single result. Three hit policies
evaluate a decision table to multiple results.

Single result decision tables

Such tables either return the output of only one rule or aggregate the output of many rules into
one result. The hit policies to be considered are

U nique: Rules do not overlap. Only a single rule can match.

F irst: Rules are evaluated from top to bottom. Rules may overlap, but only the first match
counts.

P riority: Rule outputs are prioritized. Rules may overlap, but only the match with the
highest output priority counts.

NOTE
 Camunda does not yet support the hit policy priority. In essence, priorities are specified as
an ordered list of output values in decreasing order of priority. Such priorities are therefore
independent from rule sequence! Though not yet supported, you can mimic that behavior
using hit policy "(C)ollect" and determining a priority yourself; for example, by means of an
execution listener attached to the end of your business rule task.

A ny: Multiple matching rules must not make a difference: all matching rules must lead to
the same output.

Collect and aggregate: The output of all matching rules is aggregated by means of an operator:

C+ Sum: Add up all the matching rule's distinct outputs.

C< Minimum: Take the smallest value of all the matching rule's outputs.

C> Maximum: Take the largest value of all the matching rule's outputs.

C# Number: Return the number of all the matching rule's distinct outputs.

Multiple result decision tables

Multiple result tables may return the output of multiple rules. The hit policies for such tables
are:

C ollect: All matching rules result in an arbitrarily ordered list of all the output entries.

R ule order: All matching rules result in a list of outputs ordered by the sequence of those
rules in the decision table.

O utput order: All matching rules result in a list of outputs ordered by their (decreasing)
output priority.

NOTE

Camunda does not yet support the hit policy output order. In essence, output orders are
specified as an ordered list of output values in decreasing order of priority. Such priorities
are therefore independent from rule sequence! Though not yet supported, you can mimic
that behavior using hit policy "(C)ollect" and determining an output order yourself; for
example, by means of an execution listener attached to the end of your business rule task.

Understanding DMN hit policy use cases

Most situations can be addressed using different hit policies. In that case, the hit policy will have
an effect on the readability and maintainability of the table. Often it is worth trying different
varieties until you have a feel for what will work best. In practice, we often use the free online
simulator to experiment with various alternatives.

Unique: granting categories of customers a specified discount

Hit policy "Unique" will typically make it easy to build a decision table, which ensures your rules
are "complete" - in the sense that the rules do not just not overlap but cover all possible input
values - so that you do not "forget" anything.

Customer Discount
Hit Policy:Unique

When And Then Annotations

Category Years Discount
1 1 since (in %)
string first double
purchase
string

1 "Gold" >= 5 15 -

2 "Gold" <5 12 -

3 "Silver" >= 5 9 -
2
2

4 "Silver" <5 6 -

5 "Bronze" >= 5 3 -

6 "Bronze" <5 0 -

Customer Discount
Hit Policy:Unique

When And Then Annotations

Category Years Discount
1 since (in %)
string first double
purchase
string

1 "Gold" >= 5 15 -

2 "Gold" <5 12 -
 When And Then Annotations
Category Years Discount
1 since (in %)
string first double
purchase
string

3 "Silver" >= 5 9 -
2

4 "Silver" <5 6 -

5 "Bronze" >= 5 3 -

6 "Bronze" <5 0 -

1 The input area of each row specifies a certain segment of possible input values.
2 This row, for example, expresses that long time silver customers receive a 9% discount.
Such a use case fits to the hit policy "Unique". For such use cases, it is an advantage that this hit
policy make your decision logic invalid in case you violate its requirement that your table rules
never "overlap": after all, you must not produce ambiguous results.

First: accepting a customer based on hard criteria

Having said that, the hit policy "First" can sometimes make it easier for an organization to reason
about decision logic dealing with some criteria that are "harder" (more "clearcut") than others.
Furthermore, it can help to make a decision table layout more compact and therefore easier to
interpret.

Creditworthiness
Hit Policy:First

When And Then Annotations

Rating Current Creditwortiness
(past monthly boolean
experience) net
string income
long

1 "Bad" 1 false Once the customer is on the black

1 list, we don't care about income
anymore.

2 "Good" true We always accept customers we

2 know well, even if their current net
2 income is very low or 0.
 When And Then Annotations
Rating Current Creditwortiness
(past monthly boolean
experience) net
string income
long

3 "Mixed" >= 500 true For a payment experience currently

rated as "mixed" we demand a
minimal income.

4 > 1000 true If we don't know them yet, we

demand a reasonable income for a
beginning.

5 false All other customers are declined.

3
3

Creditworthiness
Hit Policy:First

When And Then Annotations

Rating Current Creditwortiness
(past monthly boolean
experience) net
string income
long

1 "Bad" 1 false Once the customer is on the black

list, we don't care about income
anymore.

2 "Good" true We always accept customers we

2 know well, even if their current net
income is very low or 0.

3 "Mixed" >= 500 true For a payment experience currently

rated as "mixed" we demand a
minimal income.

4 > 1000 true If we don't know them yet, we

demand a reasonable income for a
beginning.

5 false All other customers are declined.

3
 1 Assume that everybody in the organization knows that first rule: "Once on the blocklist, never
again accepted." The layout and the hit policy of the decision table therefore supports the
organization's way of doing business: once we know that single fact about a customer, we don't
need to think further.
2 The following rules from row 2-4 are expressed in an "Accept" manner and might change
more often over time. The organization's way of thinking is literally "from top to bottom". Once
we find an acceptance rule, we can deal with the customer.
3 For execution in a decision engine, don't forget to add a rule not accepting any other
customers as a last row.
In scenarions dealing with hard exclusion and inclusion criteria, we often don't care that much if
the rules overlap, but prefer to argue about very clearcut cases first and about more
sophisticated ones later on. Furthermore, the organization's way of thinking and doing business
might be better supported by a decision table using the hit policy First.

Our experience so far tends to show that it can be more tricky and error prone to argue about a
First hit policy decision table than it might occur to you at first sight. Therefore, be especially
careful and always test your logic in case you are dealing with sensitive business!

Collect: deciding which groups of people may review an order

With hit policy collect, you do not care about the order or any interdependencies between your
rules at all. Instead, you just "collect" independent rules and care about the question which rules
are applicable to your specific case.

Consider, for example, the question of "who is allowed" to carry out some action, as, for example,
reviewing and deciding about incoming orders:

Order Review Groups

Hit Policy:Collect

When And Then Annotations

Order Order Review Group
category value string
string double

1 "New < "Sales" Sales of small new cars are our every day
car" 25000 business and should be reviewed by sales.

2 "Spare < 5000 "Sales" For spare parts, we need to be more cautious,
parts" because of fraud detection reasons.

3 "Pre- "Sales" When it comes to pre-owned cars, sales has

owned free hand to decide independent of order
 When And Then Annotations
Order Order Review Group
category value string
string double
car" value.

4 >= "Management" All cases may be decided by management,

5000 too. But they should not even see the very
small ones.

Order Review Groups

Hit Policy:Collect

When And Then Annotations

Order Order Review Group
category value string
string double

1 "New < "Sales" Sales of small new cars are our every day
car" 25000 business and should be reviewed by sales.

2 "Spare < 5000 "Sales" For spare parts, we need to be more cautious,
parts" because of fraud detection reasons.

3 "Pre- "Sales" When it comes to pre-owned cars, sales has

owned free hand to decide independent of order
car" value.

4 >= "Management" All cases may be decided by management,

5000 too. But they should not even see the very
small ones.

As a result of this decision table, we will either get ["Sales"] or ["Management"] or a list of both
groups ["Sales", "Management"] .

We could use this information to route the order into the applicable group's task lists or control
access rights of a configurable software solution, etc. Of course, you could at any time introduce
more rules and eventually also differentiate between more groups without changing your
software solution.

Sum: accepting a customer based on soft criteria

Hit policy "collect" may be combined with operators such as Sum (C+), leading to very different
use cases. A very typical one is the requirement to evaluate a case based on manyfold factors
influencing the overall result.
Assume, for example, that we want to deal with customers we know nothing about. They receive
a score of 0. But in case we know something about them, we also weigh in our knowledge:

Creditworthiness 1 1

Hit Policy:Collect (Sum)

When And Then Annotations

Rating Current Creditworthiness
(past monthly integer
experience) net
string income
long

1 "Bad" -15 If we have bad experience you start

with -15 points.

2 "Good" 2 15 If we have good experience you start

2 with +15 points.

3 < 500 -10 For a very low income we deduct -10

3 3 points.

4 >= 1000 5 For a reasonable income we add 5

points.

5 >= 2000 10 For a good income you receive 10

4 4 points extra.

Creditworthiness 1

Hit Policy:Collect (Sum)

When And Then Annotations

Rating Current Creditworthiness
(past monthly integer
experience) net
string income
long

1 "Bad" -15 If we have bad experience you start

with -15 points.

2 "Good" 2 15 If we have good experience you start

with +15 points.

3 < 500 -10 For a very low income we deduct -10

3 points.
 When And Then Annotations
Rating Current Creditworthiness
(past monthly integer
experience) net
string income
long

4 >= 1000 5 For a reasonable income we add 5

points.

5 >= 2000 10 For a good income you receive 10

4 points extra.

1 The overall creditworthiness is deducted by throwing in many factors.

2 Here, for example, we give credit in case we made good experiences with the customer in the
past.
3 A very low current income does not matter as long as the customer is not a stranger to us!
4 On the other hand, as soon as a customer has proof for a good income, they receive five
points for "reasonable" income as well as 10 points extra for good income.
Even if we had bad experience with a customer (which means they start from -15), we end up
with an overall score of 0 in case the customer has a good income now, and start to accept the
customer again.

In scenarions dealing with soft exclusion and inclusion criteria, we need a mechanism to
associate a weight to different scenarios. This is ideally supported by hit policy Sum (C+).

Tags: DMN

Edit this page