Decision Table / Rules

Decision Tables are a powerful feature in Unmeshed that allow you to replace complex if-else conditions with a structured, tabular approach to business rule management. This feature provides flexibility by allowing you to manage decision logic independently from your process definitions.

Overview

Decision Tables enable you to define business rules in a spreadsheet-like format where you specify input conditions and corresponding output decisions. This approach offers several advantages:

• Simplified Logic: Replace complex nested if-else statements with clear, tabular rules
• Independent Management: Manage decision logic separately from process definitions
• Easy Maintenance: Update rules without modifying process code
• Visual Clarity: See all conditions and outcomes in a single view
• Import/Export: Work with familiar spreadsheet tools for rule management

Creating a Decision Table

Basic Structure

A Decision Table consists of:

• Inputs: Columns that define the conditions to evaluate
• Outputs: Columns that specify the resulting decisions or actions
• Rules: Rows that define specific combinations of input conditions and their corresponding outputs
• Descriptions: Optional text to document the purpose of each rule

Input Conditions

Input columns support various condition types:

• Numeric Comparisons: > 750, < 650, between(650, 750)
• Wildcards: * (matches any value)
• Exact Matches: Specific values for categorical data

Output Decisions

Output columns define the resulting actions or decisions based on the matched input conditions. These can be:

• Categorical Values: AUTO_APPROVE, REJECT, APPROVAL_MANAGER
• Numeric Results: Calculated values or scores
• Action Codes: References to specific process steps or workflows

Rule Strategies

Decision Tables support two rule matching strategies:

First Match

• Evaluates rules in order from top to bottom
• Returns the output of the first rule where all input conditions are met
• Stops evaluation after finding the first match
• Ideal for scenarios where rule priority matters

All Match

• Evaluates all rules and returns outputs for every matching rule
• Can specify a limit to control the maximum number of matches returned
• Useful when multiple outcomes are possible or when you need to collect all applicable rules
• Provides comprehensive analysis of all matching conditions

Import and Export Functionality

Importing from Spreadsheets

Decision Tables can be imported from spreadsheet files (Excel, CSV) to quickly populate rules:

1. Click the Import button in the Decision Table interface
2. Select your spreadsheet file
3. Map columns to inputs and outputs
4. Review and validate the imported rules

Exporting to Spreadsheets

Export your Decision Tables to spreadsheet format for:

• External Review: Share with business stakeholders
• Backup: Create copies of your rule sets
• Analysis: Use spreadsheet tools for rule analysis
• Collaboration: Allow non-technical users to modify rules

1. Click the Export button
2. Choose your preferred format (Excel, CSV)
3. Download the file with all current rules and configurations

Testing Decision Tables

The Test Runner allows you to validate your Decision Table logic before using it in production processes.

Test Input Configuration

• Input Values: Specify test values for each input column
• Variable Selection: Use dropdown menus to change input variables
• Dynamic Inputs: Add or remove input variables as needed

Test Execution

• Rule Strategy: Choose between "First Match" or "All Match" for testing
• Limit Setting: For "All Match", specify the maximum number of results
• Test Run: Execute the rules with your test data
• Results Display: View the output decisions and matched rules

Example Test Scenario

Using the loan approval example:

• CreditScore: 721
• AnnualIncome: 120001
• LoanAmount: 230001
• DebtToIncomeRatio: 20

Result: APPROVAL_MANAGER (matches the rule for high-income, high-credit applicants with large loan amounts)

Integration with Unmeshed Processes

Decision Tables are used as steps within Unmeshed processes, providing a clean way to implement complex business logic.

Process Integration

1. Add Decision Table Step: Include a Decision Table step in your process definition
2. Configure Inputs: Map process variables to Decision Table input columns
3. Specify Outputs: Define which Decision Table outputs to capture
4. Rule Strategy: Choose the matching strategy for your use case

Input Mapping

Similar to the test runner, you specify input values by:

• Mapping process variables to Decision Table input columns
• Providing dynamic values based on previous step outputs
• Using templated values from the process context

Output Handling

Decision Table outputs can be:

• Stored in Variables: Save results for use in subsequent steps
• Used for Branching: Control process flow based on decisions
• Passed to Other Steps: Use outputs as inputs for downstream processing

Best Practices

Rule Design

• Clear Conditions: Use specific, unambiguous input conditions
• Logical Ordering: Arrange rules in order of priority (for First Match strategy)
• Comprehensive Coverage: Ensure all possible scenarios are covered
• Documentation: Add descriptions to explain complex rules

Use Cases

Decision Tables are particularly effective for:

• Approval Workflows: Loan approvals, expense approvals, access requests
• Classification Systems: Customer segmentation, product categorization
• Routing Logic: Message routing, task assignment, workflow branching
• Compliance Rules: Regulatory compliance, policy enforcement
• Scoring Systems: Risk assessment, performance evaluation

Rule Definition Syntax

Decision Tables support a comprehensive set of operators and syntax patterns for defining conditions. Understanding these patterns is crucial for creating effective decision rules.

Basic Comparison Operators

Numeric Comparisons

• Greater than: > 750
• Greater than or equal: >= 21
• Less than: < 650
• Less than or equal: <= 30
• Equal: = 25 or == 25
• Not equal: != 0

String Comparisons

• Exact match: = "APPROVED" (case-insensitive)
• Not equal: != "REJECTED"

Boolean Comparisons

• True values: = true, = yes, = "true", = "yes"
• False values: = false, = no, = "false", = "no"

Range and Set Operators

Between Operator

Defines a range of values (inclusive on both ends):

• Numeric ranges: between(650, 750), between[1000, 3000]
• Date ranges: between(2023-01-01, 2023-12-31)
• String ranges: between(A, C) (lexicographic comparison)

Examples:

age: between(18, 65)
income: between(30000, 100000)
applicationDate: between(2023-01-01, 2023-12-31)

In Operator

Checks if a value is in a list of options:

• Bracket syntax: in[electronics, books, clothing]
• Parenthesis syntax: in(electronics, books, clothing)
• Separator variations: in[red,blue,green], in[red # blue # green], in[red - blue - green]

Examples:

category: in[electronics, books, clothing]
status: in(APPROVED, PENDING, REJECTED)
region: in[US, CA, UK]

Not In Operator

Checks if a value is NOT in a list:

• Bracket syntax: notin[toys, games, books]
• Parenthesis syntax: notin(toys, games, books)

Examples:

category: notin[restricted, banned]
status: notin(REJECTED, CANCELLED)

String Pattern Matching

Contains Operator

Checks if a string contains a substring:

• Syntax: contains:substring or contains(substring)
• Case-insensitive matching

Examples:

productCategory: contains:phone
description: contains(urgent)

Starts With Operator

Checks if a string starts with a prefix:

• Syntax: startsWith:prefix or startswith(prefix)
• Case-insensitive matching

Examples:

filename: startsWith:report
name: startswith(Sam)

Ends With Operator

Checks if a string ends with a suffix:

• Syntax: endsWith:suffix or endswith(suffix)
• Case-insensitive matching

Examples:

filename: endsWith:.csv
extension: endswith(.pdf)

Like Operator (SQL-style)

Pattern matching with wildcards:

• Syntax: like:pattern or like(pattern)
• Wildcards: % (any characters), _ (single character)
• Case-insensitive matching

Examples:

description: like:%phone%
username: like:user%
filename: like:%.csv

Regex Operator

Regular expression pattern matching:

• Syntax: regex:pattern or regex(pattern)
• Full regex support

Examples:

username: regex:^user.*
email: regex:^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
phone: regex:^\d{3}-\d{3}-\d{4}$

Length Operators

String Length Comparisons

• Exact length: len=5 or len(5)
• Minimum length: len>3
• Maximum length: len<10

Examples:

code: len=5
password: len>8
description: len<100

Wildcard Operator

Universal Match

The * wildcard matches any value:

Examples:

age: *
category: *
status: *

This is particularly useful for:

• Catch-all rules: Rules that apply regardless of specific input values
• Default conditions: When other conditions don't match
• Optional fields: When a field may or may not be present

Complex Boolean Expressions

Decision Tables support complex boolean logic with AND/OR operators and parentheses:

Basic Boolean Logic

• AND operator: and (case-insensitive)
• OR operator: or (case-insensitive)
• Parentheses: () for grouping

Examples:

age: >=18 and <=65
income: >50000 or creditScore >750
status: (APPROVED or PENDING) and notin[REJECTED, CANCELLED]

Operator Precedence

• AND has higher precedence than OR
• Use parentheses to override precedence

Examples:

# This: >=10 and <=20 or =5
# Is interpreted as: (>=10 and <=20) or =5

# This: >=10 and (<=20 or =5)
# Is interpreted as: >=10 and (<=20 or =5)

Complex Combinations

You can combine multiple operators in complex expressions:

Examples:

# Multiple conditions with different operators
text: contains(abc) and notin[x,y] and len>5

# Range and set operations
value: between(10, 100) and notin[50, 75]

# String patterns with boolean logic
filename: (startsWith:report or startsWith:summary) and endsWith:.pdf

# Regex with other conditions
username: regex:^user.* and len>3 and notin[admin, root]

Date and Time Handling

Decision Tables automatically parse and compare dates in various formats:

Supported Date Formats

• yyyy-MM-dd: 2023-12-25
• yyyy-MM-dd HH:mm:ss: 2023-12-25 14:30:00
• yyyy-MMM-dd: 2023-Dec-25
• yyyy-MM-dd'T'HH:mm:ss: 2023-12-25T14:30:00
• yyyy-MM-dd'T'HH:mm:ss.SSS: 2023-12-25T14:30:00.123

Date Comparisons

All comparison operators work with dates:

Examples:

applicationDate: <=2023-01-01
createdDate: between(2023-01-01, 2023-12-31)
expiryDate: >2024-12-31

Empty and Null Handling

Empty Cells

• Empty input cells: Treated as wildcards (match any value)
• Empty output cells: Included in results as empty strings

Null Values

• Null context values: Skip rules that require those fields
• Null rule expressions: Treated as wildcards

Rule Evaluation Examples

Here are practical examples showing how different rule combinations work:

Example 1: Loan Approval with Multiple Conditions

age: >=21 and income: >50000 and creditScore: >=600
# Matches: age=25, income=60000, creditScore=750
# Result: APPROVED

Example 2: Product Categorization

category: in[electronics, books] and price: between(10, 100) and stock: >0
# Matches: category=electronics, price=75, stock=5
# Result: AVAILABLE

Example 3: User Access Control

role: notin[guest, blocked] and (department: contains:IT or clearance: >=5)
# Matches: role=employee, department=IT Support, clearance=3
# Result: GRANTED

Example 4: File Processing Rules

filename: (startsWith:report or startsWith:summary) and endsWith:.pdf and size: >1000
# Matches: filename=report_2023.pdf, size=2048
# Result: PROCESS

Example: Loan Approval Decision Table

The loan approval example demonstrates a typical Decision Table implementation:

CreditScore	AnnualIncome	LoanAmount	DebtToIncomeRatio	Decision	Description
> 750	> 50000	< 100000	< 30	AUTO_APPROVE	Low-risk, small loan
between(650, 750)	> 40000	< 50000	< 35	APPROVAL_1	Standard approval
< 650	*	*	*	REJECT	Poor credit score
> 700	> 60000	between(10000, 200000)	< 40	APPROVAL_2	Medium-risk approval
> 720	> 120000	between(200000, 300000)	< 40	APPROVAL_MANAGER	High-value loan

This structure allows for clear, maintainable business logic that can be easily modified without touching process code.