Components of a Decision Table

Learn what are the components of a Decision Table in ProcessMaker Platform.

Overview

The Decisions Table package must be installed to use Decision Table Editor.

A Decision Table is a two-dimensional grid that outlines the different possible business conditions that can occur for a particular data output. The data output then affects the workflow routing for any Request that references that decision table. The Decision Table represents business rules from which to evaluate how to route Requests for a Process. Below is a Decision Table edited in Decision Table Editor. Decision Tables are Decision Model and Notation (DMN) files.

What is a Decision?

A Decision Table is a set of decisions. Each row in a Decision Table represents one decision. In the example in the Overview, there are three decisions. As a best practice, describe each decision for greater clarity. Collectively, this set of decisions represents business rules for that use case.

Each decision contains the following:

  • Condition(s): Conditions are the inputs that must occur for each decision. A decision variable represents one condition in each decision. A decision may be composed of multiple conditions, and therefore affect multiple Request variables. However, each decision must have at least one input. In the example in the Overview, there are four possible inputs, though in the second decision only three inputs are evaluated; the Commercial Industry input is not considered in that decision because it either is not relevant or is not expected to be in that Request's JSON data model to be evaluated. A Decision Table may contain many decisions that apply to multiple intended Process models. Therefore, some inputs or outputs may not apply to all Process models that a Decision Table is to be referenced.

  • Output(s): The output sets the value to a specified Request variable when the input(s) for each decision occur. This output Request variable then affects workflow routing in that Request. A decision may have multiple outputs, and therefore affect multiple Request variables. However, each decision must have at least one output. Outputs in a Decision Table are denoted with blue coloring in the table header. In the example above, there is one output.

Each input and output for a decision has the following:

  • Label: Both inputs and outputs have labels that briefly describe that aspect of the decision. The label is independent of any labels used in Screen design for a control label or a Process model element label since Decision Tables are independent of Processes. Labels are in bold in the Decision Table header.

  • Decision variable name: Both inputs and outputs must have a decision variable for that input or output:

    • Input(s): The decision variable provides a value for that input to evaluate that condition. When configuring a Decision Task connector, data from the in-progress Request maps to the decision variable for each input so as to evaluate that Request data's condition.

    • Output(s): The decision variable value in that decision outputs that value to the in-progress Request's JSON data model, thereby affecting workflow routing for that Request. Therefore, it is important to understand the names of the decision variables and how they would correspond with an intended Request variable.

    Request variables display below their labels in the header.

What is a Decision Variable?

A decision variable represents the value for decision input or output. Decision variables are independent of Request variables because a Decision Table can be used in multiple Processes. The name of the decision variable can be identical to that of a Request variable, but is not required. After a Decision Task connector references a Decision Table during its configuration, map the referenced Decision Table's variables to and from the Request variables to transfer Request data to and from the Request. Therefore the decision variable names can be the same or different from the names of Request variables intended to transfer data.

By default, decision variables are of string data type. A decision variable may be of any of the following data types:

  • boolean: The decision variable represents one of two possible values (usually denoted TRUE and FALSE).

  • date: The decision variable represents a date. The date is in the following format: YYYY-MM-DD. Example: "2020-07-01".

  • datetime: The decision variable represents a datetime. The datetime is in the following format: YYYY-MM-DD HH:MM:SS. Example: "2020-07-01 14:25:15".

  • number: The decision variable represents a number.

  • string: The decision variable represents a string.

  • time: The decision variable represents a time. Example: 14:25:15.

Conditions and Examples Using Conditions

The following are some examples of conditions. Take into account that the Decision Tables package uses the Drools engine to evaluate business rules, which is based on the Decision Model and Notation (DMN) and Friendly Enough Expression Language (FEEL) standards. Therefore, to view more condition examples, see Drools Documentation and Drools DMN FEEL handbook.

  • String examples: See the following examples that use strings within conditions:

    • Concatenate strings by using the + symbol as follows:

      "some" + "string" = "somestring"
    • Split strings using the split function. The next example splits a string by specifying the delimiter symbol, in this case that is space (\\s).

      split( "John Doe", "\\s" ) = ["John", "Doe"]
  • Date example: The following example uses a date, specifically to get its year by using .year after the date:

    date( "2022-12-31" ).year = 2022
  • Number examples: See the following examples that use number ranges within conditions. These examples use range syntax instead AND or OR operators, which are not supported by the DMN and FEEL specifications:

    • A range where the number is greater than or equal to 100000 and less than 199999:

      [ 100000 .. 199999 ]
    • A range where the number is less than 100000:

      ] 0 .. 99999 ]

Mustache Syntax in Conditions

Use mustache syntax {{variable_name}} to use Request variables and Magic Variables in your Decision Table conditions. In this way, expressions can compare input values against other dynamic variables coming from the request data model. This syntax avoids hard-coded constant values.

There are different uses, such as the following:

  • Some FEEL expressions require an explicit reference to the variable. For example, contains(variable, string). Use mustache brackets to reference the variable in order to search for the string inside of it. You may also use mustache brackets to reference a separate value for a string if it is not a constant.

  • Follow these steps to reference Collection data:

    1. In a condition, enter {{ . A gray-colored data icon suggests possible Collections to call values within it.

    2. Select a Collection.

    3. Press the TAB key. The autocomplete enters a mustache syntax expression with a Data icon to access the selected Collection. If there are no Collections, the suggestion disappears.

© Copyright 2000-2024 ProcessMaker Inc. All rights reserved.