Decision Tables

Understand what a Decision Table is in ProcessMaker Platform.

Plan Availability:

Overview

A Decision Table is a two-dimensional grid that outlines various potential business rules and their corresponding data outputs. These outputs subsequently influence the workflow routing for any Request that utilizes the Decision Table. Essentially, the Decision Table serves as a framework for evaluating business rules and determining the appropriate routing for Process Requests.

Decision Tables are Decision Model and Notation (DMN) files. DMN is a standard notation to model and run decisions in business contexts, used by business analysts, developers, and Process designers to manage complex decision-making scenarios.

An example Decision Table for Loan Request Approval rules as edited in Decision Table Editor

Why Use Decision Tables?

Decision Tables provide the following benefits:

• Design complex sets of business rules easily and with greater readability and transparency than using Gateway-type elements with Sequence Flow elements to determine workflow routing.

• Decision Tables require no coding experience, allowing most Process designers to easily design business rules.

• Test a Decision Table to evaluated expected outcomes from decisions within the table. There is no need to start Requests to evaluate decisions.

• Decision Tables are referenced from within Process models, but function independently of Process models. This makes them reusable and more flexible than only using BPMN elements.

• Case data can be reference in Decision Tables using request variables.

See an example of a Decision Table that uses a Collection and variables as inputs.

Components of a Decision Table

Each row in a Decision Table represents one decision. 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:

• Input(s): Inputs, represented by decision variables, are the conditions that must occur for each decision. A decision may have one or more inputs and at lease one output.

• Output(s): When certain conditions are met in a Decision Table, an output is generated and saved in a decision variable. The decision variable must then be mapped to a Request variable which will be used for workflow routing. It's essential for each decision to have at least one output, however, a Decision Table can have more than one output, which means it can influence multiple Request variables. Outputs are highlighted in blue at the top of the table.

Each input and output for a decision has the following:

• Label: Labels for both inputs and outputs provide brief descriptions of their functions. These labels are distinct from those used in Screen Builder or the Modeler because Decision Tables operate independently of Processes. You can identify these labels easily in the Decision Table header as they are displayed in bold.

• Decision variable name: Both inputs and outputs must have a decision variable assigned to them. Decision variables display below their labels in the header.

Decision Variable

A decision variable represents the value of input and output columns in a Decision Table. These variables exist inside a Decision Table only, and they must be mapped to Request variables in order to access their value in a Request. The name of the decision variable can be identical to that of a Request variable, but is not required.

By default, decision variables are of string data type, but can be changed to any of the following data types:

• boolean: Represents one of two possible values (usually denoted TRUE and FALSE).

• date: Represents a date. The date is in the following format: YYYY-MM-DD. For example: 2020-07-01.

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

• number: Represents a number.

• string: Represents a string.

• time: Represents time. For example: 14:25:15.

• formula: The decision variable's value is computed using a formula. This formula can be built using Request variables, constants and arithmetic operators. For Example: price * 0.15

The formula data type can only be used for input columns in a Decision Table.

Conditions and Examples Using Conditions

The following are some examples of conditions. Take into account that the Decision Tables 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: "Spring" + "2024" = "Sring2024"

  • 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( "Kate Norris", "\\s" ) = ["Kate", "Norris"]

• Date example: The following example uses a date, specifically to get its year by using .year after the date: date( "2023-12-31" ).year = 2023

• 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 ]

• Formula examples: The following example calculates the value of a Decision column using a formula.

  • ShippingCost = weight*2

  • NetIncome = income-(income*tax)

See a detailed example of using formulas in a Decision Table

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.

Mustache examples such as using Variables and Collections

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.

View All Decision Tables

Permissions

Your user account or group membership must have the "Decision Tables: View Decision Tables" permission to view and search for Decision Tables unless your user account has the Make this user a Super Admin setting selected.

See the Decision Tables permissions or ask your Administrator for assistance.

ProcessMaker Platform displays all Decision Tables in one location. Any Decision Table developed by any Process Designer can be used in any Process. This makes it easy to manage Decision Tables.

Follow these steps to view all Decision Tables in your organization:

1. Log on to ProcessMaker Platform.

2. Click the Designer option from the top menu. The Designer Welcome Screen displays.

3. Do one of the following:

   • From the Assets pane in the Designer Welcome Screen, mouse-hover over the Decision Tables icon, and then select View All Decision Tables.
   • Click the Decision Tables icon from the left sidebar. The Decision Tables tab displays all Decision Tables in the Decision Tables page.

"Decision Tables" page displays all Decision Tables in your organization

The Decision Tables page displays the following information in tabular format about Decision Tables:

• Name: The Name column displays the name of the Decision Table. Click the name to edit the Decision Table in Decision Table Editor.

• Description: The Description column displays the description of the Decision Table. See Configure a Decision Table.

• Category: The Category column displays to which Decision Table Category the Decision Table is assigned.

• Modified: The Modified column displays the date and time the Decision Table was last modified. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.

• Created: The Created column displays the date and time the Decision Table was created. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.

Search for a Decision Table

Use the Search function to filter all Decision Tables from the Decision Tables page based on your entered text.

Follow these steps to search for a Decision Table:

1. View your Decision Tables. The Decision Tables page displays.

2. Enter in the Search setting the text to filter Decision Tables using any of the following criteria:

   • Name: Filter by the Decision Table name that displays in the Name column.

   • Category: Filter by the Decision Table Category name that displays in the Category column.

   • Description: Filter by the Screen description that displays in the Description column.

As you enter text into the Search setting, Screens display that match your entered text.

If there are no search results, the following message displays: No Results.

Related Topics

Decision Table Categories

Create a New Decision Table

Import from Excel or CSV

Import and Export a Decision Table

Test a Decision Table

Manage a Decision Table