Decision Table

Decision Tables are a powerful technique to represent a set of related business rules in the form of a multi-dimensional matrix. They are exceptionally useful in modeling and maintaining complex business situations in a simple manner.

A Decision Table supports entering a multi-axis grid combining multiple Conditions with resulting Actions. The resulting matrix of Conditions/Actions is displayed in a precise yet compact tabular manner, as rows of Decisions, which can be easily managed by business users. The Decision Table evaluates from the top down until it finds a path where all conditions resolve to True. Business experts can easily check the logic represented in a Decision Table for Consistency, Completeness, and Correctness.

It is generally beneficial to use a Decision Table in order to avoid repeating conditional logic in nested “If” statements. Every row created in the Decision Table includes a column for each defined Condition and Action.

The Decision Table has its own Tab with a ribbon with buttons to add, edit, delete, and organize the decisions, as well as check/generate your rows against all possible permutations of the conditions and actions.

Name

Specifies the name of the Decision Table.

Compatibility mode

When checked, the identity of conditions that evaluate and actions that execute will include the row identifier (e.g. Row3).

This means that any expression or action whose identity influences its execution may be affected by this setting:

• GetElementId() syntax function will include the Row identifier (e.g. Entity1:1/RuleSet1/ DecisionTable1/Row3/SetValue1 as opposed to Entity1:1/RuleSet1/DecisionTable1/SetValue1)
• FireNotification action will fire for each row that matches (if Exit at first true is unchecked), even if multiple notifications is unchecked
• The identity of rules and actions in the Rule Engine Feedback in irVerify (Rule Execution Log) will include the row identity

The downside of the Compatibility mode is that the rule application cold-start will be significantly longer, and rule execution will be slower.

If unchecked, row identifiers are not included in the above scenarios resulting in identifiers for conditions and actions appearing relative to the table, not the current row. This results in a much shorter cold start and faster rule execution.

If the Run Mode of the parent rule set is auto-optimized, Compatibility mode is the only option and must be used.

Exit at first true

When checked, the Decision Table will stop evaluating rows after a row matches its conditions and executes its actions.

If unchecked, execution continues to evaluate the remaining rows in the table and executes actions for any row whose conditions match.

Conditions

Conditions may be built for each Field value that is desired to compare individual values or ranges of values.

Actions

Actions are created to assign a Field a value as the result of a decision table match.

Decisions

Rows of decisions are various conditions combined with actions.

Conditions

Each defined Condition Set creates a corresponding column in the Decision Table. Specific instances of named Expressions are defined for each Condition in a Condition set, which will populate the selections for each row in the Condition's column within the Decision Table.

There are many options for defining Conditions: Simple field comparison, Syntax Expression, business language expression, or building the conditions from a value list.

Condition Name

Specifies the name of the Condition Set that appears in the Decision Table Column Header.

Include 'Any' in Condition Set

Adds the 'Any' option to the list of Conditions, which provides for a "catch-all" that essentially triggers the Condition to True.

Link to Input Field

Specifies if the Condition Set relates to a specific Field in which case the Field Condition editor may be used.

Field Name

Name of the Field the Condition is linked to.

Use Value List

If the Condition is linked to a Field, a value list may be selected to automatically populate the Condition Set.

Actions

The end result of the logic path through a Decision Table is determined by a set of defined actions. Multiple Action Sets can be defined (each being a column in the Decision Table) with many actions for each set. These actions will then be available to associate with a row of Conditions in the body of the Decision Table.

Action Mode

Selects either a simple Set Value editor or the business language editor for complex actions.

Set Value Action Settings

May populate the Set Value from a value list or enter a list of Custom Values.

Decisions

The Decision Table is ready for population when there is an available set of defined Conditions and Actions. Rows can be added to the Decision Table individually (setting Conditions for each column), or the table can be auto-generated across the exhaustive superset of Conditions.

Add/Insert

Adds a new row before the selected row.

Move Up/Move Down

Moves the selected row up or down one row.

Delete

Deletes the selected row.

Copy/Paste

Copies and Pastes rows in the table.

Sort

Displays a Sort Dialog Window to select column-by-column sorting options.

Clear All

Deletes all rows in the table

Check

Checks the Decision Table for missing or duplicate combinations of Conditions. It provides the ability to modify the table based on findings. Option to include 'Any' in the set of combinations when applicable.

Generate

Generates the Decision Table based on the exhaustive set of Condition combinations. Option to include 'Any' in the set of combinations when applicable.

Example 1 

Creating a Decision Table from the logic of a matrix or company document is another excellent way to use this type of rule construct within your rule application.

Scenario:

A hypothetical financial institution, ABC Lending, is using a mortgage matrix to determine if a home mortgage loan would be approved or denied, based on data points from a borrower(s) loan application (loan amount, credit score, income, etc).

Problem:

The lending guideline matrix that represents the business logic contains a number of different combinations of expressions that need to be evaluated to arrive at a certain decision. The combinations of expressions are derived from evaluating several different fields for numerous different values. If each row of the matrix was evaluated using syntax or language rules, it would result in a series of expressions joined by AND or OR statements as depicted in the image below. Adding another row of the matrix to this rule would increase the complexity of the rule resulting in maintenance and validation difficulties.

Solution:

Using a decision table, each column in the original business logic matrix can be mapped as a similar column in the rule application. Each unique cell value in all rows of the original matrix is added as condition or action values for the corresponding columns in the decision tables. Finally, after building condition and action columns and their values, the rows of the original matrix can be recreated in the decision table. The end result is an exact match of the original business logic table in one InRule rule authoring construct. Changes or additions to the business logic over time are easily made to the decision table control by business users.

Example:

This rule was authored using the business language editor from the first row in the mortgage matrix; the result is a rule with many nested-IF statements and associated actions.

Using the same logic and creating a decision table as pictured below, you would have eight conditions and one associated action.

Example 2 

Creating a decision table from the logic of a spreadsheet is an excellent way to use this type of rule constructs within your rule application. You can manage complex logic in a graphical view without the need to create nested-IF statements and actions.

Scenario:

A hypothetical grocery store, ABC Foods, uses spreadsheets to track the price of different items throughout each department (bakery, produce, deli, etc) of the grocery store.

Problem:

ABC Foods has several issues with the use of so many different spreadsheets throughout each department in the grocery store. One issue is trying to enforce consistency of each spreadsheet and a second issue is how difficult it is to track any revisions when there are pricing changes.

Solution:

Create a decision table from the logic of a spreadsheet, providing consistent changes and the ability to track price revisions.

Example:

The following rule was authored using the business language editor from a specific row in the spreadsheet; the result is a rule which has four nested-IF statements and an action.

Using the same logic and creating a decision table as pictured below you would have the same four conditions and one associated action.