# Defining decision logic¶

To obtain a decision, you must provide a decision logic in your DMN diagram. The decision logic is defined in a decision table. In decision tables, columns are used for input and output data, while the rows define decision rules.

In this section you will learn how to define decision logic.

To create a decision logic table, proceed as follows:

1. Select the decision element from the shape repository and drop it on the canvas as described above.

2. To deposit a decision logi, open the decision table, click the table icon in the upper left corner of the element. The Decision logic dialog opens. 3. In the tab Decision Table you can define the decision logic through creating inputs and mapping them to outputs. First, click New Input to give the input a label. 4. Now, define the type of the input by clicking Text and selecting the type of your choice, e.g. Enumeration of Values. 5. In case you chose ‘enumeration’, you need to define possible values. 6. If you chose Enumeration of values as your input/output, you can sort the values by clicking the move up and move down buttons at the right of the value. Additionally, you can have the values sorted automatically in alphanumerical order by clicking the Sort values button: 7. More inputs and outputs can be created by clicking Add Input, or Add Input and then Add Output, respectively: Once you have defined a new input, the input is added as an input data element to the canvas: 8. Now, create a rule by clicking Add rule. 9. Now, define the relation between input and output: to do this, operators and input values are set. Double-click on the respective line. The following table describes the available comparison operators.

Decision table operators
Operator Description Available for types
`equal` (for dates: `on`) Returns `true` if the input value equals the value specified in the corresponding decision table field. Enumeration, text, number, Boolean, hierarchy, date, lists of all types
`not equal` (for dates: `not on`) Returns `true` if the input value does not equal the value specified in the corresponding decision table field. Enumeration, text, number, Boolean, hierarchy, date, lists of all types
`less` (for dates: `before`) Returns `true` if the input value is less than the value specified in the corresponding decision table field. Number, date
`less or equal` (for dates: `until`) Returns `true` if the input value is less or equal than the value specified in the corresponding decision table field. Number, date
`greater` (for dates: `after`) Returns `true` if the input value is greater than the value specified in the corresponding decision table field. Number, date
`greater or equal` (for dates: `from`) Returns `true` if the input value is greater or equal than the value specified in the corresponding decision table field. Number, date
`contains` (for numbers: `included`) Returns `true` if the input value contains the value specified in the corresponding decision table field. Text, number
`not contains` (for numbers: `not included`) Returns `true` if the input value does not contain the value specified in the corresponding decision table field. Text, number
`begins with` Returns `true` if the input value begins with the value specified in the corresponding decision table field. Text
`ends with` Returns `true` if the input value ends with the value specified in the corresponding decision table field. Text
`element of` Returns `true` if the input value is also in the list of the corresponding decision table field. Enumeration, text, number, hierarchy, date
`not element of` Returns `true` if the input value is not in the list of the corresponding decision table field. Enumeration, text, number, hierarchy, date
`elements of` and `contains only` Returns `true` if the input list contains only items the list in the corresponding decision table field contains as well. Lists of all types
`contains any of` Returns `true` if the input list contains at least one item the list in the corresponding decision table field contains. Lists of all types
`contains none of` Returns `true` if the input list does not contain any item the list in the corresponding decision table field contains. Lists of all types
`valid` Returns `true` if the input value is defined (not empty) and valid. For example, if you only consider numeric values equal or greater than zero, all numeric values less than zero and all non-numeric values are not valid. Enumeration, text, number, Boolean, hierarchy, date
`not valid` Returns `true` if the input value is defined (not empty), but invalid. For example, if you only consider numeric values equal or greater than zero, all numeric values less than zero and all non-numeric values are invalid. Enumeration, text, number, Boolean, hierarchy, date
`defined` Returns `true` if the input value is defined (not empty). Enumeration, text, number, Boolean, hierarchy, date
`not defined` Returns `true` if the input value is not defined (empty). Enumeration, text, number, Boolean, hierarchy, date
10. Select input values: 1. Optionally, you can add documentation to the new rule in the column Annotations, ## Importing decision rules¶

You might have parts of your decision rules already defined in a spreadsheet. Then, you can import these decision rules into your DMN decision table, for example as a list of comma-separated values.

1. Open the decision table editor and click Import/Export - Text Import in the top-right corner: 1. Now, you can insert a set of decision rules, for example by copy and paste.

In the example below, we import a set of rules to determine a customer discount: Import the decision rules.

The rules need to comply with the following structure:

• Depending on the delimiter you choose, the entry fields of a decision table rows (rule) need to separated by a tab, semicolon or comma. Relational operators like `=` and `<=` must be part of the field they relate to.

• For each rule, you need to start a new line.

• The import only supports the following literal expressions:

• `not(value)`
• `not(value1, ..., valueN)`
• `!=value`

For example, `not(Premium, Gold, Platinum)` can exclude all customers with corresponding bonus cards.

Note

An import doesn’t overwrite existing rules. After you have imported the rules, they are appended to the decision table. The rules are appended to the decision table.

## Defining a literal expression as decision logic¶

As an alternative to the logic defined in the decision table for more experienced users, you can define a literal expression. Literal expressions represent pre-defined logical algorithms or rules that can be used to automatically create output results for decisions, often but not necessarily in a formal expression language. They are most commonly used in cases where the output of a decision is a the result of complex calculations or logical algorithms, or when the logic of the decision does not have much variation in their outputs with regards to its inputs.

Literal expressions are written in FEEL, the ‘friendly enough expression language’ specified as part of the DMN standard, which you can download along with examples for literal expression use cases at http://www.omg.org/spec/DMN/1.0/PDF. Important

If a literal expression is defined, it supersedes the decision logic in the decision table.

## Referencing a decision of another DMN diagram¶

You have also the possibility to reference a decision logic ofanother DMN diagram. 2. Now, identify the target diagram and select a decision element. Warning

In an older version of the Decision Manager you could reference a diagram without specifying a decision. Such a reference is semantically incomplete and cannot be interpreted by the Simulation and Test Lab.

## Referencing decisions in business knowledge models¶

When a business knowledge model links to a decision, referencing decision elements can reuse its logic. Such a reference is called a boxed invocation.

Boxed invocations provide decision logic and input type information as a generic function, whereas decisions that are referenced in DMN elements simply link to a decision and apply not only the input data types, but the specific input data objects.

In the following example, an insurance premium is calculated based on the applicant’s and their spouse’s risk level. For both persons, the same decision logic determines separate risk levels. A reference via a business knowledge model allows calling the linked decision model with different data inputs. In contrast, a direct link to a decision diagram would fail to distinguish between the two data sources. Reuse decision logic via business knowledge models.

You can reference decisions in business knowledge models in the same way you link them in decision elements. To apply a business knowledge model’s decision logic, proceed as follows:

1. Open the referencing decision.
2. Switch to the Invocation tab.
3. Set up a mapping between the referencing and the invoked decision’s input data: Apply a business knowledge model in a decision element.

## Configuring hit policies and completeness¶

With the help of hit policies you define how your decision table manages inputs that are handled by several rules and inputs for which no rules are defined.

There are single hit policies and multiple hit policies. Single hit policies produce one result per input, while multiple hit policies produce an array of outputs, which is then aggregated according to an aggregation scheme.

The completeness settings define whether your table is producing outputs for every possible input.

For further details, please consult the DMN specification document: http://www.omg.org/spec/DMN/1.0/PDF/

To define the hit policies and the aggregation and completeness settings, proceed as follows:

1. Click the UC label in the upper left corner of the table (UC stands for unique hit policy and a complete table). 2. In the Decision logic dialog, you can configure the hit policy, aggregation and completeness settings. 1. Click Save to save your settings.

### Verifying decision tables¶

Signavio Process Manager offers an automatic verification feature for decision tables to automatically check the completeness and consistency of rules.

To execute the automatic verification check, click the Verify button in the upper right corner of the decision table dialog: Verify the decision table.

In our example, one combination of input values is not covered by a decision rule: The verification function found an error: For one input combination, no rule exists.