Testing and Debugging QUALIA Business Rules

Introduction

Business rule validation requires systematic testing to ensure conditions evaluate correctly, actions execute as intended, source references return expected data, and performance remains acceptable under production loads. Inadequate testing leads to rules blocking valid transactions, failing to catch violations, executing incorrect actions, or degrading system performance.

Effective rule testing encompasses unit testing (individual rule validation), integration testing (multi-rule interaction), scenario testing (complete business process workflows), performance testing (execution speed under load), and edge case validation (null values, extreme conditions, boundary conditions).

QUALIA Rule Engine provides testing and debugging capabilities including validation logs (execution history and rule firing details), test mode (dry-run execution without committing changes), field value inspection (current and previous values during execution), performance metrics (execution timing), and error diagnostics (detailed failure information).

Testing methodology:

Isolated rule testing (verify single rule logic)
Positive testing (valid cases that should pass)
Negative testing (invalid cases that should fail)
Boundary testing (threshold values and limits)
Integration testing (multiple rules on same scenario)
Performance testing (timing under production volumes)
Regression testing (verify fixes don't break existing functionality)

Part 1: Unit Testing Individual Rules

Testing Conditions

Verify rule conditions trigger correctly for intended scenarios and ignore irrelevant cases.

Rule Under Test: Credit Limit Validation

Table: Sales Header (36)

Source References:

1. Customer (18)
   Link via: [36:2] = [18:1]

2. Customer Ledger Entry (21)
   Link via: [18:1] = [21:3]
   Reference Filters:
     [21:13]

Condition:

SUM(21:14) + [36:109] > [18:59]

Test Cases:

Test 1: Should Trigger - Exceeds Limit

Given:
  Customer Credit Limit: $50,000
  Current Balance: $30,000
  New Order Amount: $25,000
  
Expected:
  Condition TRUE (30,000 + 25,000 = 55,000 > 50,000)
  Rule triggers, action executes
  
Actual: [Record result]

Test 2: Should Not Trigger - Within Limit

Given:
  Customer Credit Limit: $50,000
  Current Balance: $30,000
  New Order Amount: $15,000
  
Expected:
  Condition FALSE (30,000 + 15,000 = 45,000 < 50,000)
  Rule does not trigger
  
Actual: [Record result]

Test 3: Boundary Case - Exactly at Limit

Given:
  Customer Credit Limit: $50,000
  Current Balance: $30,000
  New Order Amount: $20,000
  
Expected:
  Condition FALSE (30,000 + 20,000 = 50,000, NOT > 50,000)
  Rule does not trigger
  
Actual: [Record result]

Test 4: Edge Case - Zero Balance

Given:
  Customer Credit Limit: $50,000
  Current Balance: $0
  New Order Amount: $60,000
  
Expected:
  Condition TRUE (0 + 60,000 = 60,000 > 50,000)
  Rule triggers
  
Actual: [Record result]

Test 5: Edge Case - Negative Balance (Credit)

Given:
  Customer Credit Limit: $50,000
  Current Balance: -$5,000 (customer has credit)
  New Order Amount: $60,000
  
Expected:
  Condition TRUE (-5,000 + 60,000 = 55,000 > 50,000)
  Rule triggers
  
Actual: [Record result]

Testing Actions

Verify actions execute correctly and produce intended results.

Rule: Priority Assignment for VIP Customers

Action: Assign [36:CustomPriority] = 'High'

Test Cases:

Test 1: Field Updated

Before: [36:CustomPriority] = ''
Execute: Rule fires
After: [36:CustomPriority] = 'High'

Expected: Field = 'High'
Actual: [Record result]

Test 2: Multiple Actions Execute in Order

Actions:
  1. Assign [36:CustomPriority] = 'High'
  2. Assign [36:CustomPriorityDate] = [T]
  3. Assign [36:CustomPriorityUser] = [CurrentUser]

Expected:
  All three fields updated
  Priority = 'High'
  PriorityDate = Today's date
  PriorityUser = Current user ID

Actual: [Record results for each field]

Test 3: Conditional Action Branching

Action: IF condition THEN Action A ELSE Action B

Test 3A: Condition TRUE
  Expected: Action A executes, Action B skipped
  Actual: [Record result]

Test 3B: Condition FALSE
  Expected: Action B executes, Action A skipped
  Actual: [Record result]

Part 2: Source Reference Validation

Verifying Table Links

Confirm source references return expected records.

Rule: Vendor Lead Time Check

Source References:

1. Item (27)
   Link via: [37:6] = [27:1]

2. Item Vendor (99000785)
   Link via: [27:1] = [99000785:2]
   Reference Filters:
     [99000785:4] is true  // Preferred

3. Vendor (23)
   Link via: [99000785:1] = [23:1]

Test Cases:

Test 1: Valid Complete Chain

Given:
  Sales Line Item No.: "ITEM001"
  Item exists: Yes
  Item Vendor link exists: Yes
  Preferred vendor: Yes
  Vendor exists: Yes

Expected:
  Reference 1 returns: Item ITEM001
  Reference 2 returns: Item Vendor record
  Reference 3 returns: Vendor record
  All fields accessible

Actual: [Record which tables/records returned]

Test 2: Broken Chain - No Item Vendor

Given:
  Sales Line Item No.: "ITEM002"
  Item exists: Yes
  Item Vendor link exists: No
  
Expected:
  Reference 1 returns: Item ITEM002
  Reference 2 returns: No records
  Reference 3 returns: No records
  Rule handles gracefully (doesn't error)

Actual: [Record behavior]

Test 3: Filtered Reference Returns Subset

Given:
  Item has 3 Item Vendor records
  Only 1 marked as preferred

Expected:
  Reference returns only preferred vendor
  COUNT = 1

Actual: [Record count and which vendor returned]

Aggregate Calculation Testing

Rule: Available Inventory Calculation

Source References:

1. Sales Line (37) - Open Orders
   Link via: [27:1] = [37:6]
   Reference Filters:
     [37:SalesHeader:120]

Condition:

[27:Inventory] - SUM(37:15) < [27:15]

Test Cases:

Test 1: Aggregate Calculates Correctly

Given:
  Item Inventory: 100
  Open Order Line 1: Qty 20
  Open Order Line 2: Qty 30
  Open Order Line 3: Qty 15
  Reorder Point: 50

Calculation:
  SUM(37:15) = 20 + 30 + 15 = 65
  Available = 100 - 65 = 35
  35 < 50 = TRUE

Expected: Condition TRUE, rule triggers
Actual: [Record result]

Test 2: Filter Excludes Posted Orders

Given:
  Item Inventory: 100
  Open Order: Qty 20
  Posted Order: Qty 30 (should be excluded by filter)
  Reorder Point: 50

Calculation:
  SUM should be 20 (not 50)
  Available = 100 - 20 = 80
  80 < 50 = FALSE

Expected: Condition FALSE, rule does not trigger
Actual: [Record result]

Test 3: No Related Records

Given:
  Item Inventory: 100
  No open orders
  Reorder Point: 50

Calculation:
  SUM(37:15) = 0
  Available = 100 - 0 = 100
  100 < 50 = FALSE

Expected: Condition FALSE
Actual: [Record result]

Part 3: Scenario and Timing Testing

OnInsert Timing

Rule: Set Default Priority - OnInsert

Test Cases:

Test 1: Executes on Record Creation

Action:
  Create new Sales Header
  Set Customer No. = VIP customer

Expected:
  Rule fires immediately on insert
  Priority field populated before user modifies anything

Test Process:
  1. Click New on Sales Order list
  2. Select VIP customer
  3. Check Priority field immediately

Actual: [Record when Priority field populated]

Test 2: Does Not Execute on Modify

Action:
  Modify existing Sales Header
  Change Customer to VIP

Expected:
  OnInsert rule does not fire (record already exists)
  Priority unchanged

Actual: [Record behavior]

OnModify Timing

Rule: Track Credit Limit Changes - OnModify

Condition:

{18:59} <> [18:59]

Test Cases:

Test 1: Detects Field Change

Action:
  Change Customer Credit Limit from $50,000 to $75,000

Expected:
  OnModify fires
  {18:59} = 50,000 (old value)
  [18:59] = 75,000 (new value)
  Condition TRUE
  Audit fields updated

Actual: [Record field values and execution]

Test 2: Does Not Fire When Unchanged

Action:
  Open customer
  Modify different field (e.g., Name)
  Credit limit unchanged

Expected:
  OnModify scenario fires (field changed)
  But credit limit condition FALSE (same value)
  Credit audit fields not updated

Actual: [Record behavior]

Part 4: Multi-Rule Integration Testing

Rule Execution Order

When multiple rules apply to same scenario, verify execution order and interactions.

Scenario: Sales Order Release - Multiple rules on OnRelease

Rules:

Credit Limit Check (blocking error)
Inventory Availability Check (blocking error)
Pricing Validation (warning)
Priority Assignment (field update)

Test Cases:

Test 1: All Rules Pass

Given:
  Credit within limit
  Inventory sufficient
  Pricing valid
  VIP customer

Expected:
  Rule 1: Passes
  Rule 2: Passes
  Rule 3: Passes
  Rule 4: Executes, sets Priority = High
  Order released successfully

Actual: [Record execution sequence and results]

Test 2: First Rule Blocks

Given:
  Credit limit exceeded
  Inventory sufficient

Expected:
  Rule 1: Blocks with error
  Rules 2-4: Do not execute (operation blocked)
  Order not released

Actual: [Record which rules executed]

Test 3: Warning Rule Does Not Block

Given:
  Credit OK
  Inventory OK
  Pricing shows warning
  
Expected:
  Rule 1: Passes
  Rule 2: Passes
  Rule 3: Shows warning, does not block
  Rule 4: Executes
  Order released (user proceeds through warning)

Actual: [Record execution flow]

Rule Priority Testing

If rules have explicit priority/sequence, verify correct ordering.

Test: Execute rules in defined order even when conditions met simultaneously.

Part 5: Edge Case and Boundary Testing

Null Value Handling

Rule: Customer Balance Check

Condition:

[18:62] > [18:59]

Test Cases:

Test 1: Null Credit Limit

Given:
  Balance: $10,000
  Credit Limit: NULL / 0

Expected:
  Condition TRUE (10,000 > 0)
  Or: Rule handles null gracefully

Actual: [Record behavior]

Test 2: Null Balance

Given:
  Balance: NULL / 0
  Credit Limit: $50,000

Expected:
  Condition FALSE (0 not > 50,000)
  No error

Actual: [Record behavior]

Empty String vs. Null

Rule: Required Field Validation

Condition:

[18:CustomSalesperson]

Test Cases:

Test 1: Empty String

Field Value: ''

Expected: Condition TRUE
Actual: [Record result]

Test 2: Null

Field Value: NULL

Expected: Condition TRUE (null treated as empty)
Actual: [Record result]

Test 3: Space

Field Value: ' ' (single space)

Expected: Condition FALSE (' ' not same as '')
Actual: [Record result]

Date Boundary Testing

Rule: Overdue Invoice Alert

Condition:

[21:17] < [T]

Test Cases:

Test 1: Due Yesterday

Today: 2024-01-15
Due Date: 2024-01-14

Expected: Condition TRUE
Actual: [Record result]

Test 2: Due Today

Today: 2024-01-15
Due Date: 2024-01-15

Expected: Condition FALSE (not <, only =)
Actual: [Record result]

Test 3: Due Tomorrow

Today: 2024-01-15
Due Date: 2024-01-16

Expected: Condition FALSE
Actual: [Record result]

Part 6: Performance Testing

Execution Speed Measurement

Rule: Complex multi-table validation with aggregates

Performance Targets:

Individual rule execution: < 100ms
Complete validation set: < 500ms
High-frequency scenarios (OnModify): < 50ms

Test Process:

Test 1: Baseline Performance

Environment: Test database (1,000 records)
Action: Execute rule 10 times
Measure: Average execution time

Results:
  Execution 1: [time]
  Execution 2: [time]
  ...
  Average: [time]

Test 2: Production Volume Performance

Environment: Production-like database (100,000 records)
Action: Execute rule 10 times
Measure: Average execution time

Results:
  Average: [time]

Test 3: Concurrent Execution

Simulate multiple users triggering rule simultaneously

Setup: 10 concurrent sessions
Action: All execute same validation
Measure: Individual and total execution time

Results:
  Session 1: [time]
  Session 2: [time]
  ...
  Average: [time]
  Max: [time]

Performance Optimization Testing

Before Optimization:

Optimization Applied:

Added filters:
  [37:SalesHeader:20] >= [T] - 90  // Recent orders only
  [37:15]

After Optimization:

Part 7: Debugging Techniques

Using Validation Logs

QUALIA maintains execution logs showing rule firing history.

Log Information:

Timestamp of execution
Rule that fired
Condition evaluation result
Field values at execution time
Actions executed
Execution duration

Debugging Scenario:

Issue: Rule not firing when expected

Debug Process:

Field Value Inspection

Technique: Log field values during execution to verify condition inputs.

Example: Credit limit check not blocking as expected

Debug Action - Add Logging:

Before condition evaluation, log:
  Customer No.: [36:2]
  Credit Limit: [18:59]
  Current Balance: [18:62]
  Order Amount: [36:109]
  Total Exposure: [18:62] + [36:109]
  Condition Result: [Total] > [Limit]

Analysis:

Step-by-Step Execution

Technique: Break complex rule into components and test each part.

Complex Rule: Multi-condition with aggregates

Original Condition:

[Customer:CustomVIP] is true
AND SUM(21:14) + [36:109] > [18:59]
AND COUNT(36:* WHERE [36:CustomPastDue]

Component Testing:

Test Part 1: VIP Status

Expected: TRUE for customer C10001
Actual: [Record result]

Test Part 2: Credit Calculation

Expected: 45,000 + 15,000 = 60,000 > 50,000 = TRUE
Actual: [Record calculation and result]

Test Part 3: Past Due Count

Expected: 0 past due orders = TRUE
Actual: [Record count]

Combined:

Part 1 AND Part 2 AND Part 3
= TRUE AND TRUE AND TRUE
= TRUE (rule should fire)

Actual: [Record if rule fired]

Part 8: Testing Checklist

Pre-Deployment Testing

Unit test each rule individually
Test positive cases (should trigger)
Test negative cases (should not trigger)
Test boundary conditions (exact thresholds)
Test with null/empty values
Verify source references return correct records
Test aggregate calculations with various data
Verify field updates execute correctly
Test message text displays properly
Confirm email actions send correctly
Test scenario timing (OnInsert, OnModify, etc.)
Verify multi-rule execution order
Test performance with production volumes
Check concurrent user scenarios
Test with different user permissions
Verify error handling
Document test results

Regression Testing

When modifying existing rules:

Re-run original test cases
Verify fix resolves reported issue
Confirm no new issues introduced
Test related rules for impacts
Update test documentation

Summary and Key Takeaways

This guide covered testing and debugging QUALIA business rules:

Unit testing individual rules with positive, negative, and boundary cases
Source reference validation verifying table links and aggregates
Scenario timing testing confirming execution at correct lifecycle points
Integration testing validating multi-rule interactions
Edge case testing handling nulls, empty strings, boundary values
Performance testing measuring execution speed under load
Debugging techniques using logs, field inspection, and component testing

Testing best practices:

Test incrementally as rules are built
Create reusable test data sets
Document expected vs. actual results
Test with production-like data volumes
Verify performance meets targets
Maintain regression test suite
Use validation logs for debugging

Implementation exercise: Create comprehensive test plan:

Document rule requirements
Design test cases covering positive, negative, boundary conditions
Create test data supporting all scenarios
Execute tests systematically
Record actual results vs. expected
Debug failures using logs and field inspection
Optimize performance if needed
Document test results and findings

Related topics:

Blog 024: Aggregate Calculations (testing SUM, COUNT, AVG)
Blog 030: Understanding Scenarios (timing-specific testing)
Blog 031: Advanced Table Linking (source reference validation)
Blog 033: Performance Optimization (performance testing techniques)

This blog is part of the QUALIA Rule Engine series for Microsoft Dynamics 365 Business Central. Follow along as we explore business rule automation patterns.

Business Central

Triggering Power Automate Flows from Business Rules

Advanced Table Linking and Cross-Record Validation

Aggregate Calculations Across Related Records: Summing, Counting, and Analyzing Data

Automated Email Notifications from Business Rules

Automatically Setting Field Values with Assign Actions

Building an Approval Workflow: When Orders Need Manager Sign-Off

Building Commission Calculation Rules for Sales Teams: Automating Sales Incentives

Building Multi-Condition Validation Rules: Understanding Independent Condition Evaluation

Construction and Project-Based Industry Solutions

Creating Your First Business Rule: A Step-by-Step Beginner's Guide

Custom Validation Messages for Business Rules

Distribution and Logistics Industry Solutions

Energy and Utilities Industry Solutions

Financial Services Industry Solutions

Food and Beverage Industry Solutions

Government and Public Sector Procurement Solutions

Healthcare and Medical Supply Industry Solutions

How to Implement Credit Limit Validation in 10 Minutes

How to Link Multiple Tables for Complex Multi-Table Validation

How to Prevent Infinite Loops in Your Business Rules

How to Prevent Negative Inventory with Business Rules

How to Validate Customer Data Before Order Creation

Implementing Discount Authorization Rules: Control Pricing with Confidence

Implementing Required Field Validation: Ensuring Data Completeness

Interactive Confirmation Dialogs in Business Rules

Manufacturing Industry Solutions

Non-Profit and Grant Management Solutions

Performance Optimization for Business Rules

Pharmaceuticals and Life Sciences Solutions

Preventing Data Entry Errors: Validation Best Practices

Professional Services Industry Solutions

Real Estate and Property Management Solutions

Retail and Point-of-Sale Industry Solutions

Rule Groups and User Permissions: Controlling Who Gets Which Rules

Rule Set Organization and Maintenance

Rule Versioning and Change Management

Testing and Debugging QUALIA Business Rules

Transportation and Logistics Industry Solutions

Understanding the Rule Execution Pipeline: From Trigger to Action

Understanding Validation Scenarios and Timing

Using Old Value Placeholders for Change Detection and Validation

Understanding the Rule Execution Pipeline: From Trigger to Action

QUALIA Rule Engine operates as a sophisticated event-driven system that intercepts data changes in Business Central and evaluates configured business rules in real-time. Understanding the execution pipeline—how a database operation flows through trigger detection, scenario evaluation, condition processing, and action execution—is essential for advanced rule design, performance optimization, and troubleshooting.

Energy and Utilities Industry Solutions

Energy and utilities companies face complex regulatory requirements including FERC compliance, NERC reliability standards, environmental regulations, rate case filings, renewable energy credit tracking, interconnection agreements, demand response programs, and outage management protocols. Asset-intensive operations with critical infrastructure, regulatory cost recovery mechanisms, time-of-use pricing structures, and customer meter-to-cash processes demand automated validation beyond standard ERP capabilities.

Real Estate and Property Management Solutions

Real estate and property management companies require specialized business rules for lease administration, tenant billing, common area maintenance (CAM) reconciliation, security deposit tracking, maintenance workflow management, vacancy management, rent escalation calculations, and portfolio performance analysis. Multi-entity property ownership structures, percentage rent calculations, operating expense recoveries, lease abstraction accuracy, and compliance with lease accounting standards (ASC 842 / IFRS 16) demand automated validation beyond standard ERP capabilities.

Get Your FREE Dynamics 365 Demo

Transform your business operations with Microsoft Dynamics 365 Business Central

Experience the transformative power of Microsoft Dynamics 365 Business Central for yourself! Request a free demo today and see how our solutions can streamline your operations and drive growth for your business.

Our team will guide you through a personalized demonstration tailored to your specific needs. This draft provides a structured approach to presenting Qualia Tech's offerings related to Microsoft Dynamics 365 Business Central while ensuring that potential customers understand the value proposition clearly.

First Name*

Last Name*

Company Name*

Business Email*

Phone Number

Number Of Employees

Current Business Management System

Additional Information

Please read and confirm the following:

I consent to Qualia Tech processing my personal data to respond to my demo request and provide information about Microsoft Dynamics 365 solutions. I understand that I can withdraw my consent at any time. *

I agree to receive newsletters and marketing communications from Qualia Tech about products, services, and events. I understand I can unsubscribe at any time.

*Note: Fields marked with * are mandatory for processing your request.