Our approval workflow uses a decision table to route requests based on amount and department. Recently we’ve had cases where requests get stuck because the decision table returns no path. After investigation, I found these are edge cases where the department field is null or the amount is exactly at a boundary value.
The decision table has rules for amounts <5000, 5000-50000, and >50000, but when amount equals exactly 5000, it doesn’t match any rule. Similarly, when department is blank (which happens for external vendor requests), the table returns no result and the workflow stalls. I’m concerned about other edge cases we haven’t tested. What’s the best practice for handling these scenarios in decision table design?
I recommend comprehensive edge-case testing before deploying decision table changes. Create a test suite covering: null values, empty strings, boundary values, negative numbers, special characters in text fields, and combinations of edge conditions. We use automated testing with the Test Management plugin to run these scenarios against decision tables in our sub-prod instance before promoting to production.
Let me provide comprehensive guidance on all three focus areas:
Decision Table Design Best Practices:
Your decision table should follow a layered approach. Structure your rules from most specific to least specific, with the default rule at the bottom. For your amount-based routing, use inclusive ranges with clear operators: Rule 1 (amount <= 5000), Rule 2 (amount > 5000 AND amount <= 50000), Rule 3 (amount > 50000). This eliminates boundary gaps. For the department field, add explicit rules for null/empty handling before your default rule, such as: IF department IS EMPTY THEN route_to=‘vendor_review_team’. This makes edge case handling explicit rather than relying solely on the default catch-all.
Default Rule Configuration:
Every decision table must have a default rule as the last entry. Configure it with: Condition=‘else’ or all fields set to ‘*’, Order=9999 (ensures it evaluates last), Action=route to manual review queue with escalation flag set. Add a custom field ‘edge_case_type’ that gets populated when the default rule fires (e.g., ‘boundary_value’, ‘null_department’, ‘unknown_condition’). This enables tracking and analysis. The default rule should never auto-approve or auto-reject - always route to human review with context about why the default path was taken.
Edge-Case Testing Framework:
Implement systematic testing using these categories: (1) Boundary values - test exact boundary numbers, just below, just above; (2) Null/empty - test null, empty string, whitespace-only for all text fields; (3) Data type mismatches - test text in numeric fields, numbers in text fields; (4) Combined conditions - test multiple edge cases simultaneously (e.g., boundary amount AND null department); (5) Unexpected values - test negative numbers, zero, extremely large numbers, special characters. Create a test data set with at least 50 edge case scenarios and run them through the decision table in a test environment. Document which rules fire for each scenario. Use ServiceNow’s Automated Test Framework (ATF) to create repeatable test suites that run automatically before each deployment.
Monitoring Implementation:
Create a custom table ‘decision_table_edge_cases’ that logs: timestamp, decision_table_name, input_values (JSON), matched_rule, is_default_rule (boolean), workflow_instance. Set up a scheduled report that shows default rule frequency and common patterns. After 30 days of production data, analyze the logs to identify frequently occurring edge cases that warrant dedicated rules. This iterative refinement approach ensures your decision table evolves to handle real-world scenarios effectively while maintaining the safety net of the default rule.
Yes, routing to manual review is the safest approach for the default rule. For priority, decision tables evaluate rules top-to-bottom, so put your default rule at the bottom. Better yet, use the ‘order’ field to explicitly set it to 9999 or similar. For your boundary value issue, change your conditions to use <= and >= operators instead of < and >. So rules would be: <=5000, >5000 AND <=50000, >50000. This eliminates gaps at exact boundary values.