Decision tables

If you are asking a yes/no question when using an automated decision process, then a when rule serves the purpose. For example, a decision such as “Does this purchase order require additional approval?” works well with a when condition. However, if you need to test the values of multiple properties to answer questions such as “What promotional offer should the company offer?”, you can use a decision table.

For example, you can configure a decision table to determine the discount for customers at different spending thresholds. Using the decision table, customers who purchased more than USD1,000 in the previous year and have been a customer for five or more years are entitled to a 20 percent discount for purchases greater than USD50. Customers who purchase more than USD1,000 but have been a customer for less than five years are entitled to a 15 percent discount on purchases greater than USD100. Customers who do not meet either condition are not entitled to a discount.

Decision tables resemble a spreadsheet with rows and columns. This commonly used format helps non-technical users quickly understand how the decision logic works. Your organization may choose to delegate to business users responsible for updating the decision table. For example, when the organization changes its discount rates, managers need to update the rate. A delegated decision table allows these users to quickly adjust the table to make the update, rather than waiting for IT to make the changes required.

The following video describes the structure of a decision table and how decision tables evaluate information.

You can reference decision tables in decision shapes to decide which connector to use when advancing a case in a process. You can also use decision tables in declare expressions, activities, or routers.

Check your knowledge with the following interaction.

Decision tables are a good approach when you use a set of properties or expressions to arrive at a decision.

In the following example, a banking application uses a decision table for determining monthly maintenance fees. To find the correct fee, the decision table compares the account type and customer type property values on the table to the input values.

The table has rows for evaluating the correct fee for each combination. For instance, if the account type equals Checking, and the customer type equals Basic, then the system returns a value of USD10.

The following example shows how the decision evaluation works based on the account type and customer type property values.

By default, a condition uses an equal comparison operator (as configured in the previous example). If you are using numeric conditions, you can also specify greater than or less than comparison operators. For example, you can create a condition so that if the savings account balance is greater than USD1,000, then a customer is not charged any fees. You can also use value ranges to define the comparison. For instance, if the savings account balance is greater than USD500 but less than USD1,000, the customer can only be charged a checking account fee.

Check your knowledge with the following interaction.