Camunda DMN Boolean Error in Production – Root Cause and Fix
One of the most common Camunda DMN issues seen in production environments is the infamous Boolean evaluation error, where a decision table fails with a message indicating that a condition did not return a Boolean value.
This problem often:
-
Does not appear in development
-
Surfaces suddenly after deployment
-
Blocks process execution in production
In this blog, we’ll cover:
-
The exact root causes of this issue
-
Why it appears unexpectedly in production
-
Proven fixes used in real projects
🔴 Typical Error Message
You may see an error similar to:
or
This usually occurs when:
-
A process reaches a DMN decision task
-
A decision table condition is evaluated
-
Camunda expects
trueorfalse, but receives something else
🧠 Root Cause Analysis (Most Important Section)
1️⃣ Using "true" / "false" as Strings Instead of Boolean
This is the #1 root cause.
❌ Incorrect DMN condition:
or
Camunda interprets this as a String, not a Boolean.
✔ Correct condition:
or simply:
📌 DMN conditions must always evaluate to a Boolean value.
2️⃣ Input Variable Type Mismatch
In many production issues:
-
The DMN expects a Boolean
-
But the process variable is actually:
-
A
String -
Or comes from REST / form input as
"true"
-
Example:
Even though it looks correct, this is a String, not a Boolean.
3️⃣ REST API / Form Submissions Converting Booleans to Strings
This commonly happens when:
-
Variables are passed via REST
-
Forms submit values as strings
-
External systems send
"true"/"false"
The DMN engine does not auto-convert strings to Boolean.
4️⃣ FEEL Expression Returning Non-Boolean
Example of problematic FEEL expression:
This returns a String comparison, not a Boolean.
Correct FEEL expression:
✅ How to Fix the Issue (Production-Safe Solutions)
✔ Solution 1: Fix the DMN Conditions (Best & Fastest)
-
Remove quotes from Boolean values
-
Ensure conditions return
trueorfalse
Correct examples:
✔ Solution 2: Enforce Boolean at Process Level
Before calling DMN:
-
Convert variables explicitly
Example (Java Service Task):
This ensures DMN receives a Boolean, not a String.
✔ Solution 3: Validate Variables Before DMN Execution
Add a validation step:
-
Script task
-
Service task
Check:
-
Variable existence
-
Variable type
Fail early instead of breaking in DMN.
✔ Solution 4: Fix REST Payloads
When starting processes via REST, send Booleans properly:
❌ Wrong:
✔ Correct:
⚠️ Common Mistakes to Avoid
❌ Using "true" / "false" in DMN
❌ Assuming Camunda auto-converts types
❌ Skipping variable validation
❌ Testing only with Cockpit / Tasklist and not REST
🏗️ Best Practices for Production
-
Always define clear variable types
-
Keep DMN logic simple and explicit
-
Validate inputs before DMN
-
Align:
-
REST payload
-
Process variables
-
DMN input types
-
-
Test DMN with real production-like data
🎯 Why This Happens Mostly in Production
In development:
-
Variables often come from forms
-
Values are controlled
In production:
-
REST calls
-
External systems
-
Multiple integrations
➡️ Type mismatches become unavoidable unless explicitly handled.
📌 Final Thoughts
Camunda DMN Boolean errors are not engine bugs.
They are almost always caused by type mismatches or incorrect FEEL expressions.
Once you enforce:
-
Proper Boolean values
-
Clean DMN conditions
-
Early validation
These issues disappear completely.
💼 Professional Support Available
If you are facing issues in real projects related to enterprise backend development or workflow automation, I provide paid consulting, production debugging, project support, and focused trainings.
Technologies covered include Java, Spring Boot, PL/SQL, Azure, and workflow automation (jBPM, Camunda BPM, RHPAM).
📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 Website: IT Trainings | Digital metal podium
Comments
Post a Comment