# DMN literal expressions

Some decisions are a calculation rather than a set of rules: a total, a score, a date. Expressing those as a one-row table is awkward, and a literal expression is the intended alternative.

It is a single FEEL expression producing the decision's output.

---

## What this is for

* Calculations rather than rule sets.
* Decisions that combine other decisions arithmetically.
* Anything you would otherwise write as a table with one row.

---

## How it works

| **Action**                | **How**                                                                       |
| ------------------------- | ----------------------------------------------------------------------------- |
| Create                    | Choose a literal expression as the decision's logic instead of a table.       |
| Write FEEL                | One expression, using the decision's inputs by name.                          |
| Type                      | Set the output type reference so downstream decisions know what they receive. |
| Reference other decisions | By name, as declared in the requirements diagram.                             |

---

## A few things that catch people out

* Input names must match the requirements diagram, or the expression cannot resolve them.
* Keep expressions short. A long one is a table that has not been written yet.
* Set the output type. Downstream decisions rely on it.

---

## Related

[DMN properties panelNames, ids, documentation and Camunda fields.](https://help.gocapable.com/diagrams/dmn-properties-panel.html)

[Import and export DMN XMLStandard files, in and out.](https://help.gocapable.com/diagrams/import-and-export-dmn-xml.html)

[DMN editorBack to the editor overview.](https://help.gocapable.com/diagrams/dmn-editor.html)

---

_Draw the map before writing the rules._