Skip to main content
Nodes are the building blocks of workflows. You connect them with edges to define how data flows from start to finish. Nodes are divided into three categories that follow the natural flow of data:
  • Triggers bring documents in
  • Actions process them
  • Outputs deliver the results

​
Triggers

Trigger nodes define how documents enter the workflow. Every workflow must have at least one trigger.

Upload trigger

Accept documents uploaded through the UI

Email trigger

Receive documents via an auto-generated email address

Webhook trigger

Accept documents submitted via the API

Forward trigger

Accept a document forwarded from another workflow

​
Actions

Action nodes process documents and transform data. You can chain multiple actions together. The Business Central and QuickBooks connector nodes look up, create or update records in the middle of a run.

Parse action

Extract raw text from documents using OCR

Extract action

Pull structured data from documents using AI

Classify action

Classify documents by content type using rules or sample documents

Review action

Pause for human review and approval

Transform action

Reshape, convert, or script-process data

If action

Branch a run into a true path and a false path

Switch action

Branch a run into several named cases with a fallback

Filter action

Keep or drop document pages by content or page number

Split action

Cut one upload into page groups and run each as its own sub-document

Merge action

Combine data from multiple branches

Validation action

Validate data with rules, schemas, endpoints, scripts, or AI

HTTP action

Call an external HTTP endpoint and use the response

Reconcile action

Compare two sources and flag differences

Loop action

Run a group of nodes once per item in an array

Wait action

Pause the run on a timer or until a webhook resumes it

Retry From action

Correct input data and start a linked attempt from an earlier action

Variable action

Define named values that live within a single run

Store action

Persist keyed values across runs and workflows

Prompt action

Generate typed data with an AI prompt

Business Central

Look up, create or update a Business Central record

QuickBooks

Look up, create or update a QuickBooks Online record

​
Outputs

Output nodes deliver results outside Ingestly. Most of them end a workflow path. The Callback output is the exception: it hands the receiving system’s response to the steps after it, so a path can continue past it.

Callback output

Send results to an external webhook URL

Email output

Send results via email

Call workflow action

Run another workflow as a reusable section on this document

Forward output

Hand a classified segment to another workflow

Download output

Capture the run payload as a downloadable file

​
Node output convention

Every node’s runtime output follows the same shape:
  • payload - the node’s primary data (the response body, extracted value, retrieved store value, filtered markdown, etc.)
  • metadata.<slot> - auxiliary information specific to the node type (request details, counts, provenance). The slot name matches the node type, for example metadata.http, metadata.store, metadata.classify, metadata.split, metadata.forward, metadata.callback, metadata.email, metadata.parse, metadata.forwardOutput.
  • success - boolean indicating whether the node completed without error
  • error - error details when success is false
Use this in downstream template expressions as {{nodeName.payload.<field>}} or {{nodeName.metadata.<slot>.<field>}}.

​
Preview nodes

Some nodes are marked with a Preview badge in the workflow editor. Preview nodes are fully functional but may change in future releases. The current preview nodes are the Filter, Split, Transform, Reconcile, Loop, and Prompt actions. The Forward trigger, the Forward output, the HTTP action, the Validation action, the Variable action, the Merge action, and the Store action are no longer in preview.

​
Retries

Every action and output node has three optional retry settings, all in the editor properties panel. Retry wait pins a fixed gap between attempts. Every gap is exactly the value you set, rather than growing. Leaving it blank is not the same as setting it to 1: blank keeps the default backoff.
Retries only help with failures that can succeed on a later attempt, such as a timeout or a briefly unreachable endpoint. A step that fails the same way every time, like a template that cannot resolve, fails on the first attempt and is not retried.

​
Continue on fail

Turn Continue on fail on when a step is optional and its failure should not fail the whole run. Once the retry attempts are exhausted:
  • The step still reports Failed, and you still see it as failed in the run detail.
  • Nothing downstream of it runs. The failure is not converted into an output, so the node’s normal connections do not fire.
  • The run finishes as Completed instead of Failed.
This is the same outcome as connecting the node’s error port to something, without needing the connection. If you have already routed an edge from the error port, the failure is handled either way and the toggle changes nothing.
Continue on fail is not supported inside a loop body. A failing body node aborts the whole loop, so the flag could never apply, and saving a workflow that sets it on a body node raises a validation error.

​
Node controls in the editor

In the workflow editor, a node’s right-click menu lets you disable a node (it is skipped on the next run without deleting it) and re-enable it later. You can also copy, duplicate, copy a reference to, and rename a node inline. From a node’s hover toolbar you can pin a mock output: author a fixed JSON payload the node returns so downstream nodes can be built and tested without running the node for real.

​
Summary

See credits for detailed pricing per node type.