Skip to main content

Literal Expression

A Literal Expression is a text box containing a FEEL expression.

Usage​

Use a literal expression when the decision logic is a formula, mathematical calculation, or simple conditional that doesn't fit well in a table.

Examples​

Simple Math:

(MonthlyIncome * 12) + Bonus

If-Then-Else:

if Score > 80 then "High" else "Normal"

Filtering a List:

Orders[Amount > 1000]

FAQ​

When should I use a Literal Expression vs a Decision Table?

Use a Literal Expression when the logic is a formula or a single conditional — (Income * 12) + Bonus or if Score > 80 then "High" else "Normal". Use a Decision Table when the logic is a set of rules over a small number of inputs that maps to one or more outputs. Rule of thumb: if you can write the logic as one FEEL expression that fits on a line or two without nested ifs, a Literal is fine, if you'd need three or more nested ifs, a Decision Table is more readable and the hit policy will catch overlapping rules for you.

Can a Literal Expression call a Business Knowledge Model or a function?

Yes — the body is a FEEL expression, so it can invoke any function in scope: BKMs defined in the same DMN model (via FEEL invocation syntax myBKM(Age: 30, Income: 50000)), built-in FEEL functions, and inline function(...) definitions. Using a boxed Invocation is purely a modelling preference — it surfaces the parameter bindings as a visual table instead of a function call written in FEEL syntax.

What FEEL features can I use in a Literal Expression?

Everything FEEL supports: arithmetic, if-then-else, list filters (orderItems[item.price > 100]), for loops, quantified expressions (some, every), function invocations, context literals, and all standard built-ins. A Literal Expression is just a FEEL expression with no extra restrictions — it's the most flexible boxed expression in the spec. If you find yourself reaching for nested boxed expressions for clarity, consider whether a Context (with named intermediate steps) would be easier to maintain.