Decision Tables

Decision tables consist of a number of normalizer columns that define a set of business logic (one or more condition sets) that can be reused in different circumstances. Decision tables can be combined with a set of results into any type of component table, such as a policy table, rollover table, rate table, GL transaction type table and account table, filter, or priority generator.

MATRIXX Charging Application and MATRIXX Policy Application use decision tables for multi-parameter decisions. A decision table is a multi-dimensional matrix in which each dimension of the table represents one decision parameter. A decision table is a condition set; it does not have any results. After you create a decision table, you can assign it to a component table where you then specify the results for that type of component. For example, you can define a decision table that normalized on the range of a particular balance. That same decision table could be assigned to a rate table, policy table, and filter. In the rate table, the results would be rating formulas; in the policy table, the results would be policy profiles; in the filter, the results would be either Apply or Do Not Apply.

When used with normalizers, each dimension of a matrix is associated with a normalizer, which selects an index for that dimension. For complex decisions that are based on one or more normalizer parameters, the decision table requires one column for each normalizer that is required and one row for each possible combination of the normalization parameter values. The parameter values in a row specify a rule set that lists the conditions that must be present during rating for a result to be chosen. For simple decisions that are not based on variable parameters, a decision table has a single row that, once added to a component table of a pricing item, is used to specify a policy, rating formula, filter decision, or priority, based on the pricing item that contains it.

For example, Figure 1 shows a decision table that has two columns. The first one contains a normalizer that determines a result value based on the time-of-day a call is made and the second column contains a normalizer that determines a result based on the device type.

Figure 1. Call Time/Device Type Decision Table

When the decision table is used by a component table such as a rate table, policy table, rollover table, GL transaction type or account table, priority generator, or filter, a third Result column is added to the component table. Then each row (each condition set) of the decision table can be assigned a different result value in the pricing item containing the decision table. The result value can be as follows:

For a rate table, the result is a rating formula, a skip, or a denial.
For a policy table, the result is a skip or a specified policy profile.
For a rollover table, the result is a skip or a specified rollover profile.
For a General Ledger transaction type table, the result is a skip or a specified transaction type.
For a General Ledger account table, the result is a skip or a specified GL account.
For a priority generator, the result is a product offer priority.
For a filter, the result is either Do Not Apply (0) or Apply (1).
For a balance state update component, the result is either a balance state update profile or a skip.
For a final unit indication (FUI) generator, the result is either a FUI profile or a skip.

Separating the condition set from the result value enables the same decision table to be reused across all these pricing items. Before creating the pricing items that use a decision table, determine if the same decision table can be used multiple times.

Note: Decision tables have a size limit of 65535 rows. This limit also applies to rate tables, policy tables, and normalizers.