Decision table evaluation in decision-management module causing workflow delays

We’re experiencing significant performance issues with decision tables in our decision-management module. Our loan approval workflow uses a decision table with about 180 rules evaluating customer credit scores, income levels, and loan amounts. The evaluation is taking 4-8 seconds per request, causing noticeable delays in our approval process.

The decision table checks multiple conditions including indexed attributes like customer_type and credit_score, but we’re not seeing the expected performance. We’ve noticed the workflow slows down particularly during peak hours when multiple applications are being processed. Has anyone dealt with similar decision table performance bottlenecks? We’re considering splitting the large table or moving some logic to microflows, but unsure about the best approach for optimization.

Thanks for the response. Yes, we have indexes on customer_type and credit_score, but the rules aren’t ordered by frequency - they’re grouped by loan type instead. We have about 60 rules for personal loans, 70 for business loans, and 50 for mortgage applications. Could the rule ordering really make that much difference? Also, we’re calling this decision table from within a microflow that handles multiple validation steps.

Let me provide a comprehensive solution addressing all the optimization areas:

Decision Table Rule Optimization: Split your 180-rule table into three focused tables: PersonalLoanDecisions (60 rules), BusinessLoanDecisions (70 rules), and MortgageDecisions (50 rules). Create a routing microflow that selects the appropriate decision table based on loan_type attribute. Within each table, reorder rules by frequency - place your most commonly matched scenarios (e.g., standard credit score ranges) at the top. This alone should reduce evaluation time by 40-50%.

Indexed Attribute Usage: Ensure all frequently queried attributes used in decision conditions have database indexes. Beyond customer_type and credit_score, add indexes to loan_amount, employment_status, and debt_to_income_ratio if you’re using these in conditions. Review your index strategy monthly as your rule patterns evolve.

Splitting Large Tables: Beyond loan type splitting, consider a two-tier approach: implement a fast-path decision table with 20-25 rules covering your most common scenarios (approximately 70-80% of applications). Only route to detailed decision tables when fast-path evaluation returns “requires_detailed_review”. This dramatically improves average response time.

Performance Monitoring: Implement custom logging in your routing microflow to track decision table evaluation times. Log the loan_type, decision_table_used, evaluation_time_ms, and rule_matched for each request. Set up alerts when evaluation exceeds 2 seconds. Use Mendix Application Performance Monitor (APM) to identify slow rules and optimize them iteratively.

Microflow Offloading: Move all calculated attributes and database retrievals out of decision table conditions. Create a PrepareDecisionInput microflow that:

  1. Retrieves related entity data (customer history, existing loans, credit bureau data)
  2. Calculates derived values (debt ratios, risk scores, eligibility flags)
  3. Stores results in temporary attributes on your application entity
  4. Passes the enriched entity to the decision table

This preprocessing approach ensures decision tables evaluate against pre-calculated values, reducing evaluation time from 4-8 seconds to under 1 second in most cases. For your peak hour performance, consider implementing caching for frequently accessed reference data like interest rate tables and eligibility matrices.

Implement these changes incrementally, starting with the table splitting and microflow preprocessing. Monitor performance after each change to measure impact. You should see immediate improvement from splitting alone, with additional gains from each subsequent optimization.

Yes, moving pre-calculations to microflows is often the right approach. Here’s what I’d recommend based on your situation. The calculated attributes querying related entities are your primary bottleneck - those should definitely be moved to microflow logic that runs before decision table evaluation.