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:

Cannot evaluate expression: condition expression returns non-Boolean: result has class java.lang.String and not java.lang.Boolean

or

FEEL expression did not return a Boolean result

This usually occurs when:

  • A process reaches a DMN decision task

  • A decision table condition is evaluated

  • Camunda expects true or false, 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:

= "true"

or

= "false"

Camunda interprets this as a String, not a Boolean.

✔ Correct condition:

= true

or simply:

true

📌 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:

{ "approved": "true" }

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:

approved = "true"

This returns a String comparison, not a Boolean.

Correct FEEL expression:

approved = true

✅ How to Fix the Issue (Production-Safe Solutions)

✔ Solution 1: Fix the DMN Conditions (Best & Fastest)

  • Remove quotes from Boolean values

  • Ensure conditions return true or false

Correct examples:

approved = true amount > 1000 not(isValid)

✔ Solution 2: Enforce Boolean at Process Level

Before calling DMN:

  • Convert variables explicitly

Example (Java Service Task):

execution.setVariable( "approved", Boolean.parseBoolean( execution.getVariable("approved").toString() ) );

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:

"approved": { "value": "true" }

✔ Correct:

"approved": { "value": true }

⚠️ 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).


Comments

Popular posts from this blog

jBPM Installation Guide: Step by Step Setup

Scopes of Signal in jBPM

OOPs Concepts in Java | English | Object Oriented Programming Explained