Problem: Equation conditions currently only support comparing strings (via ==/!=), numbers (via >/>=/</<=), substrings (Contains), and variable presence (exists) — there’s no boolean type. Since tool responses commonly return native JSON booleans (e.g. "done": true), and dynamic variables are otherwise documented as always being strings, it’s genuinely ambiguous to a builder what the correct right-hand-side value should be when comparing against a boolean-producing field: the literal string "true", an unquoted boolean, "True" vs "true" casing, etc. This ambiguity is significant enough that even Retell’s own support team gave us a definitive-sounding but incorrect answer (recommending an unquoted boolean literal) that contradicted the documented equation behavior and real observed variable values in our own call data.
Concrete impact: We spent significant debugging time chasing what looked like a type-mismatch bug based on that advice, before confirming via real call data that the variable was in fact already a lowercase string "true" the whole time, matching our original (correct) condition. The actual bug turned out to be unrelated (see Feature Request 1). The lack of clarity here cost real time and led support itself to misdiagnose the issue.
Request: Either (a) add a proper boolean type to equation conditions, so a true/false tool result can be compared directly and unambiguously without a string-casing guessing game, or (b) at minimum, document explicitly and consistently — in both the transition-conditions doc and support guidance — exactly how boolean values from tool responses get coerced when written into a dynamic variable (casing, string vs. native type), so builders don’t have to reverse-engineer it from production call data.