EzFlowEzFlow Docs
Core concepts

Executions & Jobs

How workflow runs are tracked, queued, and inspected.

Every time a Workflow runs — whether from a trigger firing or a manual test — EzFlow creates a Job. A Job is a complete record of that execution: when it started, how long it took, and what every node produced.

The Job and Action model

RecordWhat it is
JobOne execution of a Workflow. Stores the status, startedAt, finishedAt, and duration, and links back to the Workflow that ran.
ActionOne node's execution within a Job. Stores the node type (moduleType), status, the input payload, the output, and per-node timing.

A single Job contains one Action per node that executed. You can inspect both at Run history and in the Job & Action model reference.

How a run works

  1. The trigger fires and the orchestrator loads the committed DAG snapshot for the active branch.
  2. Comment nodes (annotation-only nodes used for documentation on the canvas) are stripped out before execution begins.
  3. The engine executes each node in graph order, injecting each node's output into the input handles of its downstream nodes via the edges.
  4. A trackingId is propagated across all actions in the run so the full execution stays correlated.
  5. When all nodes complete, the Job status is set to COMPLETED.

COMPLETED vs WAITING

The execution engine produces one of two outcomes:

  • COMPLETED — every node ran to completion. The Job is closed.
  • WAITING — a node paused execution pending an external event — for example, a Wait for Event node waiting for an inbound communication. The engine saves an execution snapshot and the Job remains open. When the awaited event arrives, execution resumes from exactly where it left off. See Wait & resume.

Reliability

EzFlow uses an outbox pattern for persisting Job and Action records, ensuring execution state is durable even if a node fails mid-flight. Failed node executions are captured in a FailedItem record and can be retried.

On this page