You build decision tables by adding columns and rows. Each column represents a condition, while rows store corresponding values that the system tests at run time. For example, you can build a decision table to determine shipment costs based on the following conditions:
- The value of the order
- The weight of the parcel
- Whether the shipment is to a foreign country
Each condition is a separate column in the decision table. Additionally, every decision table includes a column that stores results that the decision table returns if all values in a row evaluate to true.
Each row includes cells that store values that the system evaluates at run time. You can insert more than one value in a cell by adding an OR condition, and then the system continues processing a row if any of the values in the cell evaluate to true.
At run time, the system evaluates the rows starting at the topmost row:
- If any condition in a row evaluates to false, processing continues with the next row. The
system ignores the Return column for that row.
Note: You can leave empty cells in a row. Empty cells evaluate to true except when a cell is empty and includes an OR condition. Then, the parser ignores that cell and parses only the cell that contains a value.
- If all the conditions in a row evaluate to true, the system processes the
Actions and Return columns of that row. The
next action depends on how you configure your decision table:
- To return only one result, you can configure processing to end. The system then
returns the value in the Return column as the value of the entire
In scenarios that require only one result, such as estimating delivery costs, when you end processing after receiving the first result, you improve performance and avoid unnecessary computations.
- To return multiple results, you can configure processing to continue through all
remaining rows, performing the Actions and Return calculations for any rows for which
the conditions are all true.
For example, when the decision table returns the email address of a person in a process to approve an expense, the expense might require the approval of more than one person, based on the conditions. Such scenarios require more than one result.
- To return only one result, you can configure processing to end. The system then returns the value in the Return column as the value of the entire rule.
- If all rows in the table evaluate to false, the system returns a default result.
Applying decision tables
You can apply decision tables in the following elements of your application:
- In a flow rule, you can reference a decision table in a decision shape .
For more information, see Adding decisions to processes.
- In an activity, you can evaluate a decision tree by using the
For more information, see Creating an activity.
- A Declare Expression rule can call a decision table.
For more information, see Creating Declare Expression rules.
- A collection rule can call a decision table.
Decision table rules are instances of the Rule-Declare-DecisionTable class. Decision tables are part of the Decision category.
- Creating decision tables
To better adjust to the varied factors in your business processes, you can create a decision table. Decision tables test a series of property values to match conditions, so that your application performs a specific action under conditions that you define.
- Specifying pages and classes of a decision table rule
To ensure that a decision table accesses or updates information on clipboard pages, specify the page name and class of the pages. At run time, these pages contain the properties that a decision table references on other tabs of its rule form.
- Configuring additional options for a decision table
Adjust how your decision table works by configuring additional options. For example, you can configure how a decision table behaves after one row evaluates to true, or define which elements of a decision table are available for edits.
- More about decision tables
When you learn more about decision tables, you can better understand how to use decision tables in a way that most efficiently meets your business scenarios. For example, you can understand how decision tables are related to selected methods and activities, and how these connections affect processing at run time.
- Unit testing a decision table
You can test a decision table individually, before testing it in the context of the application that you are developing. Additionally, you can convert the test run to a Pega unit test case.
- Debugging decision tables with the Tracer
If your decision table rule does not give you the results that you expect, and you cannot determine the problem by running the rule and examining the clipboard pages, run the Tracer tool. With the Tracer, you can watch each step in the evaluation of a decision table as it occurs.