Workflow nodes

This page is the field reference for the data of each node in a Workflow definition ("what the file holds"). Each node type also has a page under Workflows that describes its panel in Studio ("how the panel behaves").

Every node section has three parts:

• Notes, written by hand: which fields take expressions, the node's outputs and edge handles, what travels in a Package, what is collected at install, and what validate and build refuse.
• Fields, generated from the node's data schema. "In the file" says what the Package does with each field: as written travels unchanged, as agent (and the like) means you write the reference instead of the stored id, and never carried means the field is left out of the file. Rows such as branches[].id are the fields of each entry of a list; inputs.<name>.value is a field of each entry of a map.
• Example, the workflow file that npx @elizon/cli example workflow --node <type> prints. The command prints it inside a complete project (the manifest and every file the node references) that passes validate and build.

For several nodes working together, run npx @elizon/cli example workflow --pattern <name>:

Expressions

A string field that takes expressions can hold {{ … }} references, resolved when the node runs: {{ trigger.body.orderId }}, {{ upstream.<node id>.output.<path> }}, {{ loop.item }}, {{ variables.<name> }}, {{ run.startedAt }}. See Referencing values.

Some rows (Edit Fields, Data Table mappings and conditions, App inputs, MCP Tool arguments, Knowledge Search filters, Human Review defaults) have a valueMode: expression resolves the value, fixed uses it exactly as written. Quote a YAML value that starts with {{, for example value: '{{ trigger.body.email }}'.

Edges and handles

An edge connects a source node to a target node. Most nodes have one output, and their edges have no sourceHandle. Three node types have named outputs, and an edge leaving one of them names the output in sourceHandle:

A Human Review node has one output, not one per decision: branch on its decision with an If/Else node, as the human-review-upsert pattern does. An edge's data is optional and only holds what the canvas records about the two ports (sourceType, targetType: text, json, agent_output or any; typeMismatch). Leave it out when you write a file by hand. targetHandle is not used.

- { id: order-to-route, source: order, target: route }
- { id: route-large, source: route, target: approval, sourceHandle: large }
- { id: route-default, source: route, target: standard, sourceHandle: default }
- { id: each-line-body, source: each-line, target: line-total, sourceHandle: loop }
- {
    id: each-line-done,
    source: each-line,
    target: collect,
    sourceHandle: done,
    data: { sourceType: json, targetType: any },
  }

What validate and build refuse

These apply to every node. A node's own section lists the ones particular to it.

Triggers

A workflow holds at least one trigger. A run starts from the trigger that fired, and a workflow can hold any number of Manual triggers but at most one Webhook, Form, Email, App and Recurrence trigger each. A trigger has no input handle.

trigger_manual

The Manual trigger (node page) starts a run on demand.

• Expressions: none. Later nodes read the run's input flat, as {{ trigger.<field> }}.
• Handles: one output.
• In a Package: description travels. Nothing is collected at install.
• Refusals: only the ones every node has.

Fields (from ManualTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_manual prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Manual trigger example
description: An operator starts the run from the web app with a request.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: Paste the customer request as `request`.
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.request }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: start-to-keep, source: start, target: keep }

trigger_recurrence

The Recurrence trigger (node page) starts a run on a schedule: every intervalValue intervalUnit in interval mode, or on a five-field cronExpression in cron mode, in timezone (a tz-database name such as Europe/Berlin).

• Expressions: none; a scheduled run's trigger payload is empty. Use {{ run.startedAt }} for the time.
• Handles: one output.
• In a Package: the whole schedule travels. Nothing is collected at install.
• Refusals: a second Recurrence trigger in the workflow (PORTABLE_DEFINITION_INVALID).

Fields (from RecurrenceTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_recurrence prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Recurrence trigger example
description: Runs at 08:00 Berlin time on weekdays.
graph:
  nodes:
    - id: every-morning
      type: trigger_recurrence
      position: { x: 0, y: 0 }
      data:
        mode: cron
        cronExpression: 0 8 * * 1-5
        timezone: Europe/Berlin
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ run.startedAt }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: every-morning-to-keep, source: every-morning, target: keep }

trigger_http

The Webhook trigger (node page) starts a run from an HTTP request. fields declares the body it expects; each is checked on every call.

• Expressions: none on the node. Later nodes read the body as {{ trigger.body.<name> }}.
• Handles: one output.
• In a Package: method and fields travel. webhookSecret is never carried; the endpoint and its token are created when the installed workflow is published.
• Refusals: a second Webhook trigger in the workflow (PORTABLE_DEFINITION_INVALID).

Fields (from HttpRequestTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_http prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Webhook trigger example
description: Takes an order the shop posts.
graph:
  nodes:
    - id: order-received
      type: trigger_http
      position: { x: 0, y: 0 }
      data:
        method: POST
        fields:
          - name: orderId
            type: string
            required: true
          - name: total
            type: number
            required: true
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.body.orderId }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: order-received-to-keep, source: order-received, target: keep }

trigger_form

The Form trigger (node page) renders a public form and starts a run when it is submitted.

• Expressions: none. Later nodes read each answer as {{ trigger.body.<name> }}.
• Handles: one output.
• In a Package: fields and authMode travel. basicAuthUsername is never carried, and the password is never on the node: with authMode: basic, the username is collected at install, in the wizard or as --form-user.<node id>=….
• Refusals: a second Form trigger in the workflow (PORTABLE_DEFINITION_INVALID).

Fields (from FormTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_form prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Form trigger example
description: Takes a service request from a public form.
graph:
  nodes:
    - id: request-form
      type: trigger_form
      position: { x: 0, y: 0 }
      data:
        authMode: none
        fields:
          - name: email
            label: Your email
            type: email
            required: true
          - name: machine
            label: Machine
            type: dropdown
            required: true
            options:
              - X200
              - X300
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.body.machine }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: request-form-to-keep, source: request-form, target: keep }

trigger_email

The Email trigger (node page) polls an IMAP mailbox every pollMinutes and starts one run per message that passes the filters.

• Expressions: none. Later nodes read the message flat: {{ trigger.subject }}, {{ trigger.from.address }}, {{ trigger.attachments }}.
• Handles: one output.
• In a Package: what to read travels (the filters, the attachment rules, format, postAction, the poll settings). The mailbox and its server never travel: host, port, security, username, password, mailbox and moveToMailbox are set on the canvas after install.
• Refusals: a second Email trigger in the workflow (PORTABLE_DEFINITION_INVALID).

Fields (from EmailTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_email prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Email trigger example
description: Reads supplier invoices that arrive in a mailbox.
graph:
  nodes:
    - id: invoice-mail
      type: trigger_email
      position: { x: 0, y: 0 }
      data:
        postAction: markRead
        filterUnseen: true
        filterSubjectContains: Invoice
        downloadAttachments: true
        attachmentExtensions: pdf
        format: simple
        pollMinutes: 5
        processExistingUnread: false
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.subject }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: invoice-mail-to-keep, source: invoice-mail, target: keep }

trigger_knowledge_document

The Knowledge Base document trigger (node page) starts a run for every document indexed into a Knowledge Base.

• Expressions: none. Later nodes read the document flat, for example {{ trigger.document_name }}.
• Handles: one output.
• In a Package: write knowledgeBase: knowledgeBases.<name>, a Knowledge Base the Package declares; the installed trigger watches the one the install creates. knowledgeBaseName is a label and is replaced by that Knowledge Base's name. Declare knowledge in compatibility.requiredCapabilities.
• Refusals: knowledgeBase missing or null (PORTABLE_DEFINITION_INVALID), or naming an undeclared Knowledge Base (UNRESOLVED_LOCAL_REFERENCE): a trigger that watches nothing could never fire.

Fields (from KnowledgeDocumentTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_knowledge_document prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Knowledge Base document trigger example
description: Runs once for every document indexed into the handbook.
graph:
  nodes:
    - id: new-document
      type: trigger_knowledge_document
      position: { x: 0, y: 0 }
      data:
        knowledgeBase: knowledgeBases.handbook
        knowledgeBaseName: Handbook
        event: indexed
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.document_name }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: new-document-to-keep, source: new-document, target: keep }

trigger_app

The App trigger (node page) polls an app every pollMinutes, for example new files in a Google Drive folder, and starts one run per new item.

• Expressions: inputs entries take a valueMode. Later nodes read the item as {{ trigger.item.<field> }}.
• Handles: one output.
• In a Package: app, trigger, inputs and the poll settings travel. A fixed value in inputs (the example's folderId) travels as written, so every install polls that same id until the operator changes it in Studio; say so in the Package's description. The account travels as connection: the id of a credential Slot with the app's account (app: google), which the operator binds to one of their connected accounts at install. Add the app's provider to compliance.providers.
• Refusals: connection naming an undeclared Slot, a Slot that is not type: credential, or one whose app is not the account the app needs (PORTABLE_UNDECLARED_REFERENCE); a second App trigger (PORTABLE_DEFINITION_INVALID). An undeclared provider is a warning (MANIFEST_APP_PROVIDER_UNDECLARED).

Fields (from AppTriggerNodeDataSchema; each row is a key of the node's data)

Output

A trigger has no upstream output: later nodes read what started the run as {{ trigger.… }} and {{ run.trigger.… }}. The node page lists the paths.

Example (npx @elizon/cli example workflow --node trigger_app prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: App trigger example
description: Runs once for every file dropped into a Google Drive folder.
graph:
  nodes:
    - id: new-file
      type: trigger_app
      position: { x: 0, y: 0 }
      data:
        app: google-drive
        trigger: file-added
        connection: google-account
        inputs:
          folderId:
            value: intake-folder-id
            valueMode: fixed
        pollMinutes: 5
        processExisting: false
        processExistingMax: 10
    - id: keep
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: field-1
            name: received
            value: '{{ trigger.item.name }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: new-file-to-keep, source: new-file, target: keep }

AI

ai_agent

The AI Agent node (node page) runs one of the Package's Agents.

• Expressions: each inputMappings[].expression.
• Handles: one output; the answer is {{ upstream.<node id>.output.text }}.
• In a Package: write mode: existing and agent: agents.<name> (or null for none chosen yet, which validate and build warn about with WORKFLOW_NODE_UNBOUND: the node installs but cannot run); the stored agentId is never in the file. agentName is a label and is replaced by the installed Agent's name. The inline mode (instructions, model and tools on the node itself) is still decoded, with llm_slot for its model, tools[].tool: tools.<name> (MCP servers only) and knowledgeSources[].knowledgeBase: knowledgeBases.<name>, but Studio no longer saves new inline nodes: use an Agent.
• Refusals: agent naming an undeclared Agent (UNRESOLVED_LOCAL_REFERENCE).

Fields (from AiAgentNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node ai_agent prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: AI Agent example
description: Has the Package’s Agent answer a request.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: answer
      type: ai_agent
      position: { x: 280, y: 0 }
      data:
        mode: existing
        agent: agents.responder
        agentName: Responder
        inputMappings:
          - field: request
            expression: '{{ trigger.request }}'
  edges:
    - { id: start-to-answer, source: start, target: answer }

team_step

The Team step (node page) hands its input to one of the Package's Teams.

• Expressions: inputExpression.
• Handles: one output; the Team's answer is {{ upstream.<node id>.output.text }}.
• In a Package: write team: teams.<name> (or null, which validate and build warn about with WORKFLOW_NODE_UNBOUND: the node installs but cannot run); teamId is never in the file. teamName is replaced by the installed Team's name. Declare teams in compatibility.requiredCapabilities.
• Refusals: team naming an undeclared Team (UNRESOLVED_LOCAL_REFERENCE).

Fields (from TeamStepNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node team_step prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Team step example
description: Hands a request to the Package’s Team.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: review
      type: team_step
      position: { x: 280, y: 0 }
      data:
        team: teams.triage
        teamName: Triage
        inputExpression: '{{ trigger.request }}'
  edges:
    - { id: start-to-review, source: start, target: review }

ai_prompt

The AI Prompt node (node page) sends one prompt to a model.

• Expressions: instructions, inputExpression, attachmentExpression.
• Handles: one output; the text is {{ upstream.<node id>.output.completionText }}.
• In a Package: write llm_slot: <slot id>, an llm Slot the manifest declares; the operator binds it to one of their LLM Configurations at install. model_id is a preference, used when that Configuration offers the model. Everything else travels.
• Refusals: a value Studio could not save (PORTABLE_DEFINITION_INVALID). An llm_slot that names no declared Slot is not caught by validate or build today; install refuses it (PORTABLE_UNRESOLVED_BINDING). Check the Slot id yourself.

Fields (from AiPromptNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node ai_prompt prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: AI Prompt example
description: Summarises a request in two sentences.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: summarise
      type: ai_prompt
      position: { x: 280, y: 0 }
      data:
        llm_slot: reasoning
        model_id: null
        instructions: Summarise the request in two sentences.
        inputExpression: '{{ trigger.request }}'
        temperature: 0.2
        maxTokens: 512
        outputFormat: text
  edges:
    - { id: start-to-summarise, source: start, target: summarise }

classify

The Classify node (node page) asks a model which of its categories the input belongs to, and routes it down that category's handle.

• Expressions: inputPrompt.
• Handles: category-<id> per category, plus category-other with noMatchAction: other_branch. With allowMultipleClasses: true several handles can fire; with noMatchAction: discard an unmatched input fires none.
• In a Package: llm_slot as for AI Prompt. Category ids are local to the graph: Studio writes UUIDs, and a short id such as billing works the same and reads better in a file.
• Refusals: as for AI Prompt.

Fields (from ClassifyNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node classify prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Classify example
description: Sends each request down the branch of its category.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: route
      type: classify
      position: { x: 280, y: 0 }
      data:
        llm_slot: reasoning
        model_id: null
        inputPrompt: '{{ trigger.request }}'
        categories:
          - id: billing
            name: Billing
            description: Invoices, payments, refunds.
          - id: technical
            name: Technical
            description: Faults, errors, how-to questions.
        allowMultipleClasses: false
        noMatchAction: other_branch
        enableAutoFixing: false
    - id: billing-queue
      type: edit_fields
      position: { x: 560, y: 0 }
      data:
        rows:
          - id: field-1
            name: queue
            value: billing
            valueMode: fixed
        keepOnlySetFields: true
    - id: technical-queue
      type: edit_fields
      position: { x: 840, y: 160 }
      data:
        rows:
          - id: field-1
            name: queue
            value: technical
            valueMode: fixed
        keepOnlySetFields: true
    - id: other-queue
      type: edit_fields
      position: { x: 1120, y: 320 }
      data:
        rows:
          - id: field-1
            name: queue
            value: general
            valueMode: fixed
        keepOnlySetFields: true
  edges:
    - { id: start-to-route, source: start, target: route }
    - {
        id: route-category-billing-to-billing-queue,
        source: route,
        target: billing-queue,
        sourceHandle: category-billing,
      }
    - {
        id: route-category-technical-to-technical-queue,
        source: route,
        target: technical-queue,
        sourceHandle: category-technical,
      }
    - {
        id: route-category-other-to-other-queue,
        source: route,
        target: other-queue,
        sourceHandle: category-other,
      }

Control flow

if_else

The If/Else node (node page) checks its branches top to bottom and takes the first whose expression is true, or defaultBranchId.

• Expressions: each branches[].expression, for example '{{ trigger.body.total }} > 10000'.
• Handles: each branch id, and defaultBranchId. Exactly one is taken; the nodes after the others are skipped.
• In a Package: everything travels. Branch ids are local to the graph: Studio writes UUIDs (and branch-1 for the first), and a short id such as large works the same.
• Refusals: only the ones every node has.

Fields (from IfElseNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node if_else prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: If/Else example
description: Sends large orders one way and the rest another.
graph:
  nodes:
    - id: order
      type: trigger_http
      position: { x: 0, y: 0 }
      data:
        method: POST
        fields:
          - name: total
            type: number
            required: true
    - id: check-total
      type: if_else
      position: { x: 280, y: 0 }
      data:
        branches:
          - id: large
            label: Over 10 000
            expression: '{{ trigger.body.total }} > 10000'
        defaultBranchId: default
    - id: needs-approval
      type: edit_fields
      position: { x: 560, y: 0 }
      data:
        rows:
          - id: field-1
            name: status
            value: needs approval
            valueMode: fixed
        keepOnlySetFields: true
    - id: accepted
      type: edit_fields
      position: { x: 840, y: 160 }
      data:
        rows:
          - id: field-1
            name: status
            value: accepted
            valueMode: fixed
        keepOnlySetFields: true
  edges:
    - { id: order-to-check-total, source: order, target: check-total }
    - {
        id: check-total-large-to-needs-approval,
        source: check-total,
        target: needs-approval,
        sourceHandle: large,
      }
    - {
        id: check-total-default-to-accepted,
        source: check-total,
        target: accepted,
        sourceHandle: default,
      }

loop

The Loop node (node page) runs its body once per item of sourceArray, with up to batchSize iterations at the same time (1, the default, runs them one after another).

• Expressions: sourceArray. Inside the body, {{ loop.item }} and {{ loop.index }}.
• Handles: loop (the body) and done (runs once, after the last item). After the loop, read a body node's results as {{ upstream.<body node id>.output.iterations }}, a list with one entry per iteration (output itself is { iterations, loopNodeId }).
• In a Package: everything travels.
• Refusals: only the ones every node has. A Wait node inside a loop body fails the loop at run time.

Fields (from LoopNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output }} (an array).

Note: Reference this Loop’s BODY NODES directly instead — after the loop, {{ upstream.<body node id>.output.iterations }} is an array of that node’s own output, one entry per iteration, which is what you almost always want. The body node’s output holds that array under iterations, beside loopNodeId.

Example (npx @elizon/cli example workflow --node loop prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Loop example
description: Runs one step per order line, then one step when every line is done.
graph:
  nodes:
    - id: order
      type: trigger_http
      position: { x: 0, y: 0 }
      data:
        method: POST
        fields:
          - name: lines
            type: object
            required: true
    - id: each-line
      type: loop
      position: { x: 280, y: 0 }
      data:
        sourceArray: '{{ trigger.body.lines }}'
        batchSize: 1
    - id: line-total
      type: edit_fields
      position: { x: 560, y: 0 }
      data:
        rows:
          - id: field-1
            name: total
            value: '{{ loop.item.quantity }} x {{ loop.item.price }}'
            valueMode: expression
        keepOnlySetFields: true
    - id: collect
      type: edit_fields
      position: { x: 840, y: 160 }
      data:
        rows:
          - id: field-1
            name: totals
            value: '{{ upstream.line-total.output }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: order-to-each-line, source: order, target: each-line }
    - {
        id: each-line-loop-to-line-total,
        source: each-line,
        target: line-total,
        sourceHandle: loop,
      }
    - { id: each-line-done-to-collect, source: each-line, target: collect, sourceHandle: done }

wait

The Wait node (node page) pauses the run for amount unit (interval), or until at in timezone (until).

• Expressions: at.
• Handles: one output.
• In a Package: everything travels.
• Refusals: only the ones every node has.

Fields (from WaitNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node wait prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Wait example
description: Waits three days before the next step.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: three-days
      type: wait
      position: { x: 280, y: 0 }
      data:
        mode: interval
        amount: 3
        unit: days
        at: ''
        timezone: Europe/Berlin
    - id: follow-up
      type: edit_fields
      position: { x: 560, y: 0 }
      data:
        rows:
          - id: field-1
            name: due
            value: '{{ run.startedAt }}'
            valueMode: expression
        keepOnlySetFields: true
  edges:
    - { id: start-to-three-days, source: start, target: three-days }
    - { id: three-days-to-follow-up, source: three-days, target: follow-up }

human_review

The Human Review node (node page) pauses the run until a reviewer answers, or until the timeout. In single mode the reviewer answers once (responseFields); in batch mode they approve, edit or reject each item of itemsExpression (itemFields).

• Expressions: title, message, itemsExpression, itemLabel (with {{ item.<field> }}), and each field default with valueMode: expression. assignedTo too: see below.
• Handles: one output. Branch on {{ upstream.<node id>.output.decision }} (approved or rejected) with an If/Else node; a batch review's approved list feeds a Loop.
• In a Package: the file carries approverRequired. Leave assignedTo out and set approverRequired: true, and the approvers are collected at install (in the wizard, or --approver.<node id>=…). Or set assignedTo to {{ }} expressions only (for example '{{ trigger.body.managerEmail }}') and approverRequired: false: it travels, and the installer's answer becomes the fallback. fallbackAssignedTo is never carried.
• Refusals: a literal address in assignedTo is stripped by build, with the warning HUMAN_REVIEW_APPROVER_STRIPPED (from validate too).

Fields (from HumanReviewNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

More paths follow from the node’s own configuration; the node page lists them.

Example (npx @elizon/cli example workflow --node human_review prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Human Review example
description: Asks finance to approve a refund before anything else happens.
graph:
  nodes:
    - id: refund-request
      type: trigger_http
      position: { x: 0, y: 0 }
      data:
        method: POST
        fields:
          - name: amount
            type: number
            required: true
    - id: approve-refund
      type: human_review
      position: { x: 280, y: 0 }
      data:
        title: Refund of {{ trigger.body.amount }}
        message: Approve or reject this refund.
        mode: single
        responseFields:
          - name: notes
            type: long_text
            default:
              value: Looks fine.
              valueMode: fixed
        timeoutValue: 2
        timeoutUnit: days
        onTimeout: reject
        approverRequired: true
  edges:
    - { id: refund-request-to-approve-refund, source: refund-request, target: approve-refund }

Data and files

variable

The Variable node (node page) sets a run-scoped variable that every later node reads as {{ variables.<name> }}.

• Expressions: initialValue.
• Handles: one output.
• In a Package: everything travels.
• Refusals: only the ones every node has.

Fields (from VariableNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Note: Prefer {{ variables.<name> }} — this node also declares a run-scoped variable.

Example (npx @elizon/cli example workflow --node variable prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Variable example
description: Stores whether a ticket is urgent, for every later step to read.
graph:
  nodes:
    - id: ticket
      type: trigger_http
      position: { x: 0, y: 0 }
      data:
        method: POST
        fields:
          - name: urgent
            type: boolean
            required: true
    - id: priority
      type: variable
      position: { x: 280, y: 0 }
      data:
        name: urgent
        type: boolean
        initialValue: '{{ trigger.body.urgent }}'
  edges:
    - { id: ticket-to-priority, source: ticket, target: priority }

edit_fields

The Edit Fields node (node page) builds an object from rows, one field per row.

• Expressions: each rows[].value with valueMode: expression.
• Handles: one output; each row is {{ upstream.<node id>.output.<name> }}.
• In a Package: everything travels.
• Refusals: only the ones every node has.

Fields (from EditFieldsNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output }} (an object).

More paths follow from the node’s own configuration; the node page lists them.

Example (npx @elizon/cli example workflow --node edit_fields prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Edit Fields example
description: Maps a lead form onto the field names a CRM expects.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: crm-fields
      type: edit_fields
      position: { x: 280, y: 0 }
      data:
        rows:
          - id: r1
            name: contact_name
            value: '{{ trigger.name }}'
            valueMode: expression
          - id: r2
            name: source
            value: website
            valueMode: fixed
        keepOnlySetFields: true
  edges:
    - { id: start-to-crm-fields, source: start, target: crm-fields }

convert_to_file

The Convert to File node (node page) turns a value into a stored file (format), which Send Email, AI Prompt, Code and Data Table nodes can use.

• Expressions: sourceExpression, filename.
• Handles: one output; the file is {{ upstream.<node id>.output.file }}.
• In a Package: everything travels.
• Refusals: only the ones every node has.

Fields (from ConvertToFileNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Example (npx @elizon/cli example workflow --node convert_to_file prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Convert to File example
description: Turns a Markdown report into a PDF the run can attach.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: to-pdf
      type: convert_to_file
      position: { x: 280, y: 0 }
      data:
        sourceExpression: |-
          # Weekly report

          {{ trigger.summary }}
        format: pdf
        filename: weekly-report
        shareWith: workflow
  edges:
    - { id: start-to-to-pdf, source: start, target: to-pdf }

data_table

The Data Table node (node page) runs one resource / operation against a Data Table: row insert, get, update, upsert, bulkUpsert, delete, exists, or a table operation.

• Expressions: mappingRows[].value, conditions[].value and automaticSource.value with valueMode: expression; rowsFileExpression; cursor.
• Handles: one output. Branch on {{ upstream.<node id>.output.result.exists }} or .affected.
• In a Package: write table: dataTables.<name>, a Data Table the Package declares (or null); tableId is never in the file. tableName is a label and is replaced by the installed table's name, except on a table create, where it is the name created. An update, upsert or delete needs a key: a conditions entry naming a column (bulkUpsert keys on keyColumns instead).
• Refusals: table naming an undeclared Data Table (UNRESOLVED_LOCAL_REFERENCE). A missing key is a warning (DATA_TABLE_NODE_KEY_MISSING): the platform refuses to publish or run the node until it has one.

Fields (from DataTableNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

More paths follow from the node’s own configuration; the node page lists them.

Note: Branch on {{ upstream.<id>.output.result.exists }} (Rows exist) or {{ upstream.<id>.output.affected }} — both are plain values an If/Else can compare.

Example (npx @elizon/cli example workflow --node data_table prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Data Table example
description: Adds one row per request to the Package’s own table.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: log-request
      type: data_table
      position: { x: 280, y: 0 }
      data:
        resource: row
        operation: insert
        table: dataTables.orders
        tableName: Orders
        mapping: manual
        mappingRows:
          - id: map-1
            column: Order
            value: '{{ trigger.order }}'
            valueMode: expression
          - id: map-2
            column: Status
            value: received
            valueMode: fixed
  edges:
    - { id: start-to-log-request, source: start, target: log-request }

knowledge_search

The Knowledge Search node (node page) searches a Knowledge Base by query, metadataFilters and documentName, and returns up to maxResults documents.

• Expressions: query, and metadataFilters[].value with valueMode: expression.
• Handles: one output; {{ upstream.<node id>.output.documents }} and .count.
• In a Package: write knowledgeBase: knowledgeBases.<name>, a Knowledge Base the Package declares; knowledgeBaseName is replaced by the installed one's name. A filter's field is one of that Knowledge Base's indexConfig.metadata.fields.
• Refusals: knowledgeBase missing or null (PORTABLE_DEFINITION_INVALID), or naming an undeclared Knowledge Base (UNRESOLVED_LOCAL_REFERENCE).

Fields (from KnowledgeSearchNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Note: Attach {{ upstream.<id>.output.documents.0.file }} in Send Email (turn on Include files). Branch on {{ upstream.<id>.output.count }} to handle "nothing found".

Example (npx @elizon/cli example workflow --node knowledge_search prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Knowledge Search example
description: Finds the handbook passages about a question.
graph:
  nodes:
    - id: start
      type: trigger_manual
      position: { x: 0, y: 0 }
      data:
        description: An operator starts this run from the web app.
    - id: find-passages
      type: knowledge_search
      position: { x: 280, y: 0 }
      data:
        knowledgeBase: knowledgeBases.handbook
        knowledgeBaseName: Handbook
        query: '{{ trigger.question }}'
        metadataFilters:
          - id: by-team
            field: team
            value: support
            valueMode: fixed
        maxResults: 5
        includeFiles: false
  edges:
    - { id: start-to-find-passages, source: start, target: find-passages }

Integrations

send_email

The Send Email node (node page) sends a message through an SMTP server.

• Expressions: to, cc, bcc, replyTo, subject, body, each of attachments, and the threading ids messageId, inReplyTo, references.
• Handles: one output; {{ upstream.<node id>.output.messageId }}.
• In a Package: the message travels. The server, login and sender never do (smtpHost, smtpPort, smtpSecurity, smtpUsername, smtpPassword, fromAddress, fromName): they are set on the canvas after install, and the node fails with that reason until they are. to, cc, bcc and replyTo travel only when they are {{ }} expressions only, such as '{{ loop.item.Email }}'.
• Refusals: a literal recipient is stripped by build, with the warning SEND_EMAIL_RECIPIENT_STRIPPED (from validate too). An SMTP field in the file is refused (PORTABLE_DEFINITION_INVALID).

Fields (from SendEmailNodeDataSchema; each row is a key of the node's data)

Output

Read as {{ upstream.<node id>.output.<path> }} (an object):

Note: Store {{ upstream.<id>.output.messageId }} (e.g. in a Data Table row) to match a reply’s {{ trigger.inReplyTo }} or {{ trigger.references }} later.

Example (npx @elizon/cli example workflow --node send_email prints it with its manifest)

# A portable Workflow definition: the nodes, and the edges between them.
name: Send Email example
description: Thanks a customer by email. The SMTP server is set on the canvas after install.
graph:
  nodes:
    - id: request-form
      type: trigger_form
      position: { x: 0, y: 0 }
      data:
        authMode: none
        fields:
          - name: email
            label: Your email
            type: email
            required: true
          - name: machine
            label: Machine
            type: text
            required: true
    - id: thank-you
      type: send_email
      position: { x: 280, y: 0 }
      data:
        to: '{{ trigger.body.email }}'
        subject: Thanks for your request
        body: We received your request about the {{ trigger.body.machine }} and will reply today.
        bodyFormat: text
        attachments: []
  edges:
    - { id: request-form-to-thank-you, source: request-form, target: thank-you }

http_request

The HTTP Request node (node page) calls an HTTP API.

• Expressions: url, the query, header and body rows' names and values, queryJson, jsonBody, rawBody, binaryFileExpression, the multipart values.
• Handles: one output; {{ upstream.<node id>.output.body }}, .status.
• In a Package: the request travels. auth never does: the credential is set on the canvas after install, and until then the request is sent without one.
• Refusals: auth in the file is refused (PORTABLE_DEFINITION_INVALID).

Fields (from HttpRequestNodeDataSchema; each row is a key of the node's data)