5.2 Decision Tables & Decision Trees

5.2 Decision Tables & Decision Trees

Enterprise case lifecycles require constant decision-making: evaluating customer credit risk, determining loan interest rates, routing insurance claims to specialized adjusters, or calculating promotional discounts. Hardcoding business logic into procedural code or monolithic scripts introduces technical debt, slows down change management, and makes business policy opaque to stakeholders.

Pega Platform provides a dedicated suite of declarative decision rules that externalize and automate decision logic. By modeling business rules as standalone, modular assets, architects ensure logic is reusable across case types, testable via automated unit tests, and delegable to business operations.

---

1. Automated Decision Rules: When vs. Decision Table vs. Decision Tree

Pega provides three primary decision rule types. Selecting the appropriate rule type is a fundamental architectural competency tested on the CSA exam.

+-------------------------------------------------------------------------+
|                   PEGA DECISION RULE TAXONOMY                           |
+-------------------------------------------------------------------------+
| [1] WHEN RULE (Rule-Obj-When)                                           |
|     - Binary logic: Returns TRUE or FALSE                               |
|     - Best for simple condition gates, UI visibility, and stage skips   |
+-------------------------------------------------------------------------+
| [2] DECISION TABLE (Rule-Declare-DecisionTable)                         |
|     - Tabular matrix: Conditions (Columns) x Values (Rows)              |
|     - Returns a value or populates properties                           |
|     - Best for structured, multi-variable policy grids                  |
+-------------------------------------------------------------------------+
| [3] DECISION TREE (Rule-Declare-DecisionTree)                           |
|     - Hierarchical tree: Nested If-Else-If outline                      |
|     - Returns a value or populates properties                           |
|     - Best for asymmetric branching with divergent property checks      |
+-------------------------------------------------------------------------+

Decision Selection Criteria

• Choose a When Rule (Rule-Obj-When) when evaluating a straightforward conditional check that answers a single boolean question: "Is the order total greater than $1,000?" or "Does the customer hold a Platinum membership?"
• Choose a Decision Table (Rule-Declare-DecisionTable) when the business logic evaluates the same set of input properties across a matrix of multiple combinations to return a specific outcome: "Given Credit Tier and Loan Amount, what is the Interest Rate?"
• Choose a Decision Tree (Rule-Declare-DecisionTree) when the logic involves nested, conditional branching where subsequent conditions evaluate completely different properties depending on earlier outcomes: "If applicant is Corporate, check Revenue and Industry; but if applicant is Individual, check Age and Credit Score."

---

2. Decision Tables (Rule-Declare-DecisionTable)

A Decision Table represents business logic in a spreadsheet-like grid. It consists of condition columns, action/return columns, decision rows, and an Otherwise fallback row.

+---------------------------------------------------------------------------------------+
|                                 DECISION TABLE GRID                                   |
+------------------------------------+--------------------------+-----------------------+
| Conditions (Input Properties)      | Actions / Return Values  | Row Description       |
| .CustomerTier     | .SpendAmount   | Return Value (pyResult)  |                       |
+-------------------+----------------+--------------------------+-----------------------+
| "Gold"            | >= 10000       | 0.25                     | VIP Tier High Spend   |
| "Gold"            | < 10000        | 0.15                     | VIP Tier Base Spend   |
| "Silver"          | >= 5000        | 0.10                     | Preferred Customer    |
| "Bronze"          | [1000..5000)   | 0.05                     | Standard Discount     |
+-------------------+----------------+--------------------------+-----------------------+
| Otherwise                          | 0.00                     | Default / No Discount |
+------------------------------------+--------------------------+-----------------------+

Grid Architecture & Components

1. Condition Columns: Each column specifies an input property to evaluate (e.g., .CustomerTier, .SpendAmount) and a comparison operator (=, <, <=, >, >=, !=).
2. Action / Return Columns: Defines the output generated when a row evaluates to true. A table can return a single value (populating pyResult) or assign values directly to multiple clipboard properties.
3. Evaluation Rows: Each row contains criteria corresponding to each condition column. For a row to be true, all conditions within that row must be satisfied (logical AND across columns).
4. The Otherwise Row: Placed at the bottom of the table, this row defines the default return value if none of the preceding condition rows evaluate to true. Every well-designed decision table must account for the Otherwise path to ensure deterministic execution.

Comparison Operators and Value Syntax

Decision tables support flexible matching expressions within condition cells:

• Exact Equality: "Gold", "CA", 500.
• Numeric and Date Ranges: [10..50] (inclusive: 10 through 50), (10..50) (exclusive: 11 through 49), [10..50) (inclusive min, exclusive max).
• List / Value Set Membership: "CA", "NY", "TX" (evaluates to true if the property matches any value in the comma-delimited list; logical OR).
• Wildcard / Any Value: Leaving a cell completely blank signifies Any or wildcard. The condition for that specific column is ignored for that row.

Evaluation Modes: Stop on First Match vs. Evaluate All Rows

In Dev Studio, on the Results tab of the Decision Table, architects configure how rows are processed:

1. Stop on first true match (Default):
   • Evaluation proceeds sequentially from Row 1 downwards.
   • As soon as the engine finds a row where all conditions are satisfied, it executes the action, returns the value, and immediately halts evaluation.
   • Row Order is Critical: More specific or restrictive conditions must be placed above broader, general conditions. If a broader condition is placed first, it will "shadow" and permanently block more specific conditions below it.
2. Evaluate all rows:
   • The engine evaluates every row in the table from top to bottom, regardless of whether earlier rows were true.
   • Used when a table performs multiple property assignments or accumulates actions across different criteria (e.g., assessing multiple non-exclusive risk surcharges).

---

3. Decision Trees (Rule-Declare-DecisionTree)

A Decision Tree structures business logic into a hierarchical outline format consisting of nested if-else-if condition branches.

Decision Tree: DetermineUnderwritingQueue
├── If .ApplicantType == "Commercial"
│    ├── If .AnnualRevenue > 10000000
│    │    └── Return "ExecutiveCommercialQueue"
│    └── Else If .YearsInBusiness >= 3
│         └── Return "StandardCommercialQueue"
│    └── Otherwise
│         └── Return "HighRiskCommercialQueue"
└── Else If .ApplicantType == "Individual"
     ├── If .CreditScore >= 720 AND .DebtToIncomeRatio < 0.36
     │    └── Return "FastTrackConsumerQueue"
     └── Otherwise
          └── Return "ManualConsumerReviewQueue"
└── Otherwise
     └── Return "TriageQueue"

When to Select a Decision Tree over a Decision Table

While Decision Tables and Decision Trees can often solve similar problems, Decision Trees excel in specific structural contexts:

• Asymmetric Condition Paths: In the example above, the commercial branch tests .AnnualRevenue and .YearsInBusiness, while the individual branch tests .CreditScore and .DebtToIncomeRatio. If modeled as a Decision Table, the grid would require four separate condition columns, with half of the cells permanently blank for every row, resulting in a sparse, confusing matrix.
• Deeply Nested Business Hierarchies: When business decisions mirror organizational flowcharts where subsequent decisions are valid only if preceding branches evaluated to a specific outcome.

---

4. Architectural Comparison Matrix

---

5. Rule Delegation to Business Users

One of Pega's most powerful enterprise capabilities is Rule Delegation. Rather than submitting change requests to IT whenever pricing matrices, interest rates, or eligibility criteria shift, organizations empower operational managers to maintain decision rules directly in production.

+-------------------------------------------------------------------------+
|                     RULE DELEGATION ARCHITECTURE                        |
+-------------------------------------------------------------------------+
| 1. System Architect configures Decision Table in Dev Studio             |
| 2. Rule is placed in an unlocked PRODUCTION RULESET                     |
| 3. Production Ruleset is assigned to Business Manager's Access Group    |
| 4. Architect selects: Actions -> Delegate                               |
| 5. Manager edits Decision Table directly in App Studio or User Portal   |
+-------------------------------------------------------------------------+

Technical Prerequisites for Rule Delegation

To delegate a decision rule safely without compromising enterprise governance, three architectural requirements must be satisfied:

1. Unlocked Production Ruleset: In a production environment, core application rulesets are locked against modification. Delegated rules must reside in a dedicated ruleset designated as a Production Ruleset on the Application rule form.
2. Access Group Configuration: The Production Ruleset must be explicitly listed under the Production Rulesets array in the Access Group assigned to the business managers.
3. Delegation Execution: A developer opens the decision rule in Dev Studio, clicks Actions $\rightarrow$ Delegate, and provides business-friendly instructions and display labels.

Business Manager Experience

Once delegated, business managers access the rule via App Studio or their operational User Portal (under Configurations or Case Settings). The interface renders a simplified, business-friendly table editor. Managers can add rows, alter numeric thresholds, modify discount percentages, and save changes immediately into production without requiring a developer release pipeline or deployment cycle.

---

6. Decision Rule Conflict & Completeness Checking

To prevent logic errors during authoring, Dev Studio provides automated validation tools accessible from the Decision Table and Decision Tree toolbars:

1. Check Conflicts (Check Conflicts Button)

• Analyzes the rule to detect unreachable rows or duplicate criteria.
• For example, if Row 1 specifies .LoanAmount > 100000 returning "Standard", and Row 3 specifies .LoanAmount > 250000 returning "Premium", the Check Conflicts tool flags Row 3 as unreachable under Stop on first true match, because every value exceeding 250,000 will satisfy Row 1 first.
• Resolving conflicts requires reordering rows so that more restrictive conditions appear above broader ones.

2. Show Completeness (Show Completeness Button)

• Evaluates the mathematical permutations of all condition column values to detect unhandled data gaps.
• Highlights combinations of inputs that currently fall through to the Otherwise row without explicit business handling.
• Helps architects and business analysts verify that no edge cases are overlooked.