Skip to main content
Decision tables let you define business rules in a familiar spreadsheet format. Each row is a rule: conditions on the left, outcomes on the right.

​
Creating a decision table

  1. Open your decision graph
  2. Drag a Decision Table node onto the canvas
  3. Connect it to your Input node (or other upstream nodes)
  4. Click Edit Table to open the editor

​
Hit policies

Hit policies control what happens when multiple rows match.
PolicyBehavior
FirstReturns the first matching row (default)
CollectReturns all matching rows as an array
To change the hit policy, click on the Settings on the decision graph node.

​
First hit (default)

The engine evaluates rows top to bottom and stops at the first match. Order your rows from most specific to most general:

​
Collect

Returns all matching rows. Useful when you need to apply multiple rules:
  • Calculate all applicable fees
  • Find all matching promotions
  • Aggregate scores from multiple criteria

​
When no rows match

If no rows match the input:
  • First hit policy — Returns an empty object {}
  • Collect policy — Returns an empty array []
To handle this, add a catch-all row at the bottom with empty conditions that matches any input:
Inputs
Outputs
The last row with empty conditions acts as a default, ensuring you always get a meaningful result.

​
Adding columns

Decision tables have two column types: Input columns — Define conditions to match against incoming data Output columns — Define values to return when conditions match To add a column:
  1. Click + in the header row
  2. Select Input or Output
  3. Enter the field path (e.g., customer.tier or order.total)
  4. Give it a readable label

​
Input column types

Input columns can be configured in two modes:

​
Targeted field (unary)

The default mode. Configure a field path (like customer.revenue) in the column settings, then write simple conditions in each cell:
Inputs
Outputs
The field path is evaluated automatically — you only write the comparison operator and value.

​
Generic field (standard)

Set the field to - (empty) to write full expressions in each cell:
Inputs
Outputs
Use generic columns when you need to:
  • Compare multiple fields in one condition
  • Write complex expressions that don’t fit the unary pattern
  • Reference previous nodes with $nodes

​
Writing conditions

Input columns use unary test syntax — shorthand expressions evaluated against each cell’s value.
Inputs
Outputs

​
Condition syntax

TypeSyntaxExampleMatches
Comparison>, <, >=, <=, ==, !=>= 100Values 100 or greater
Range (inclusive)[min..max][18..65]Values from 18 to 65
Range (exclusive)(min..max)(0..100)Values between 0 and 100
List'a', 'b', 'c''US', 'CA', 'GB'Any listed value
Combinedand, or> 10 and < 50Values matching both
With functions$len($) > 5Use $ to reference the field value
Any value(empty)Matches everything
When you use $ in a targeted field column, the expression is treated as a standard expression. This lets you use functions like len($), contains($, 'text'), or upper($) == 'VALUE'.

​
Writing outputs

Output columns contain the values returned when a row matches. You can use:
  • Literal values — 100, "approved", true
  • Expressions — input.amount * 0.1
  • References — customer.defaultRate

​
Referencing previous nodes

Use $nodes to access output from upstream nodes in your graph.

​
In conditions (generic columns)

Inputs
Outputs

​
In outputs

Inputs
Outputs
This lets you build multi-stage decisions where each table can use results from earlier nodes.

​
Testing your table

  1. Click Open Simulator in the toolbar
  2. Enter test input as JSON
  3. Click Run
  4. View the matched row and output
The simulator highlights which row matched and shows the trace through your decision.

​
Best practices

Order rows by specificity — Put specific conditions before general ones when using first-hit policy. Use meaningful labels — Column labels appear in the UI and help others understand your rules. Add a catch-all row — End with a row using empty cells in all inputs to handle unexpected cases. Keep tables focused — If a table grows beyond 20-30 rows, consider splitting it into multiple tables or using a switch node.