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.

    Open the decision logic dialog.
  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.

    Label the input.
  4. Now, define the type of the input by clicking Text and selecting the type of your choice, e.g. Enumeration of Values.

    Choose the type of input.
  5. In case you chose ‘enumeration’, you need to define possible values.

    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:

    Sort the values automatically.
  7. More inputs and outputs can be created by clicking Add Input, or Add Input and then Add Output, respectively:

    Add another output.

    Once you have defined a new input, the input is added as an input data element to the canvas:

    A new 'input data' element has been created and linked to the 'decision' element.
  8. Now, create a rule by clicking Add rule.

    Add a 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.

    Define the relation between input and output.

    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:

Selection of input data.
  1. Optionally, you can add documentation to the new rule in the column Annotations,
Add additional information.

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:

Click 'Import/Export' - 'Import text'.
  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.

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.

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.

Define a literal expression.

Read more about literal expressions in the chapter Using literal expressions instead of decision tables.

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.

  1. Switch to the Link tab. The Establish link dialog opens.

    Click 'Link'.
  2. Now, identify the target diagram and select a decision element.

    Reference a decision of another DMN diagram.

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.

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.

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).

'UC' stands for a unique hit policy and a complete table.

2. In the Decision logic dialog, you can configure the hit policy, aggregation and completeness settings.

Define 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.

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.

The verification function found an error: For one input combination, no rule exists.