DecisionTable

A decision table is a tabular representation of a set of related input and output expressions, organized into rules indicating which output entry applies to a specific set of input entries.

Access

Ribbon	Simulate > DMN > Manage > DMN Expression, then select / create a Decision or BusinessKnowledgeModel
Other	Double-click on an DMN Decision or BusinessKnowledgeModel

Toolbar Options

Option	Description	See also
	Click on this button to save the configuration to the current Decision or BusinessKnowledgeModel.
	Click on this button to switch between rule-as-row and rule-as-column for the decision table.
	Click on "Sort By Input" will sort the rules by input columns; click on "Sort By Output" will sort the rules by output columns. The Columns can be dragged and dropped to organize the sorting order.
	Click on this button to merge adjacent input entry cells from different rules with the same content.
	Click on this button to unmerge entry cells that have been merged.
	Click on this button to edit parameters for the Business Knowledge Model.
	Click on this button to append an input column for the decision table.
	Click on this button to append an output column for the decision table.
	Click on this button to append a rule for the decision table
	Click on this button to show/hide the allowed values fields for the input and output columns. The allowed value defined for a input / output will be used for validation and auto completion editing.	DMN Expression Auto Completion
	Click on this button to validate the Decision Table. EA will perform a series of validations to help the modeler to pickup errors in the decision table.	DMN Expression Validation
	This button is Enabled when the decision table is defined for a BusinessKnowledgeModel. Activate tab "Input Parameter Values for Simulation", fill the values and click this button. The test result will be presented on the decision table, with the runtime values of inputs and outputs displayed and valid rule(s) highlighted. The user can use this functionality to unit test a BusinessKnowledgeModel without knowing the context and later on invoked by a Decision or other BusinessKnowledgeModel. Menu options are available for the this toolbar button. For more information, click the See also link.	BusinessKnowledgeModel & Test Harness

Decision Table Hit Policy

The hit policy specifies what the result of the decision table is in cases of overlapping rules. The single character in a particular decision table cell indicates the table type and unambiguously understand the decision logic.

Single Hit Policies:

Unique: no overlap is possible and all rules are disjoint. Only a single rule can be matched. This is the default.

Any: there may be overlap, but all of the matching rules show equal output entries for each output, so any match can be used.

Priority: multiple rules can match, with different output entries. This policy returns the matching rule with the highest output priority.

First: multiple (overlapping) rules can match, with different output entries. The first hit by rule order is returned.

Multiple Hit Policies:

Output order: returns all hits in decreasing output priority order.

Rule order: returns all hits in rule order.

Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a simple function to the outputs.

Collect operators are:

+ (sum): the result of the decision table is the sum of all the distinct outputs.

< (min): the result of the decision table is the smallest value of all the outputs.

> (max): the result of the decision table is the largest value of all the outputs.

# (count): the result of the decision table is the number of distinct outputs.

Example of Unique hit policy

Unique hit policy is the most popular type of decision table and all rules are disjoint.

Example of Priority hit policy

In table with Priority hit policy, multiple rules can match, with different output entries. This policy returns the matching rule with the highest output priority.

Note: the output order is defined as INELIGIBLE, ELIGIBLE; which means INELIGIBLE has higher priority than ELIGIBLE.

One possible simulation result may look like this:

The matching rules are highlighted, but output with INELIGIBLE is the pick based on output order.

Example of Collection-Sum hit policy

For decision table with Collect-Sum (C+) hit policy, the result of the decision table is the sum of all the distinct outputs.

In this example, the output Partial Score is calculated as 43 + 45 + 45 = 133

Set type for Input/Output Clause

The user need to set the type for Input Clause / Output Clause for the following reasons:

Display: The string will be shown in Italic font (otherwise, each string literal need to be inside quotes)
Validation: The range, gap, overlap validations are supported only on numbers.
Code Generations for typed languages like C++/C#/Java

Some user may ask, since the BKM parameter already has types defined, why do we need to define type for the Input Clauses?

The answer is: the Input Clause could be an expression.

For example: a parameter "Credit Score" is a number type, but the Input Clause could be "Credit Score > 500" is a boolean type.

Context menu on the Input/Output Clause, choose the menu item to set type for it.

Learn more