Skip to main content
assignment nodes are how you initialise variables. Each assignment has a name and an expression evaluated once and written to the top-level run context.

​
Configuration

{
  "id": "asg-1",
  "type": "assignment",
  "data": {
    "label": "Initialize Variables",
    "description": "Set up initial variables for the pipeline",
    "assignments": [
      { "name": "risk_score",         "expression": "0" },
      { "name": "rejection_reasons",  "expression": "[]" },
      { "name": "processing_start",   "expression": "datetime.now()" }
    ]
  }
}

​
Expression evaluation

Expressions are small Python-like literals or function calls. The supported surface is intentionally narrow:
ExpressionResult
0, 'pending', [], true, falseJSON literals
datetime.now()ISO-8601 datetime string at evaluation time
uuid()New v4 UUID
{{some_variable}}Interpolation from the run context (rarely needed in assignment — use the variable directly downstream)
For anything more complex, prefer the code node.

​
Why initialise

  • Accumulator variables (rejection_reasons: []) that downstream nodes append to via code transforms.
  • Tracking timestamps (processing_start) for SLA calculations.
  • Status placeholders (kyc_status: 'pending') that change as the workflow advances.
A simpler workflow can skip the assignment node entirely and let rules + decision tables write directly to the top-level context — more compact, fewer moving parts.

​
Rule

rule is the workhorse downstream of assignment — single-pass first-match conditions producing named output fields. See the rule node.