Workflows

ScreenshotWorkflow editor — blocks wired into a directed graph.

A Workflow is a directed graph of blocks. You drag blocks onto a canvas, wire them together with edges, configure each one, and run the result on demand or on a schedule. Workflows are the deterministic counterpart to the conversational Assistant: you describe the structure once and the executor runs the same graph every time.

When to reach for it

Use Workflows when:

• The structure is known in advance — fixed inputs, fixed steps, fixed outputs.
• You need a schedule, a webhook entry point, or a callable API endpoint.
• You want runs to show up in Logs with per-block timing and traces.
• You're calling deterministic blocks (API, Function, Condition, Router) more than you're calling models.

Use the Assistant instead when the structure isn't decided yet — when you're describing what you want in natural language and don't know which blocks you'll need. You can have the Assistant build a workflow for you and then keep iterating in the editor.

Anatomy

A workflow is three things on disk and one thing on the canvas.

A run materializes that graph into an execution. Per-run state lives in workflow_execution_snapshots (the resolved snapshot of blocks + edges at run time) and workflow_execution_logs (per-block timing, inputs, outputs, errors).

What's in the block library

The block registry currently exposes 249 registered block types (apps/actana/blocks/registry.ts). They group into a few families:

• Logic — Condition, Router, Loop, Parallel, Wait.
• Data + glue — Function (custom JS/TS), API (HTTP), Response, Variables.
• AI — Inference (single-shot LLM), Agents (run a Crew Agent in a Sandbox), Evaluator, Guardrails.
• I/O + control — Webhook, Human in the Loop, Workflow (sub-flow), Credential.
• Integrations — most of the registered blocks are tool-backed integrations (Slack, GitHub, Notion, Airtable, …). They surface entries from tools/registry.ts (~2,500 tool operations) as configurable workflow blocks. See the Tools reference.

Triggers

A workflow needs at least one trigger to be runnable. Triggers live in triggers/registry.ts and the docs cover the four user-facing ones:

• Start — a manual run from the editor or API.
• Schedule — cron-style scheduled runs.
• Webhook — inbound HTTP triggers a run.
• RSS — poll an RSS feed for new items.

A workflow can have multiple triggers — useful for the same logic running on a cron and being callable on demand.

Connections

Blocks pass data through edges. The shape of the data, how to reference an upstream block's output (<blockName.field>), and how typing flows through the graph are covered in Connections.

Run, log, deploy

• Run — click Run, or call POST /api/workflows/{id}/run, or fire a webhook trigger. The executor resolves the graph and walks it.
• Log — every run lands in Logs with per-block timing, inputs, outputs, and errors. The graph is snapshotted at run time, so logs reflect the workflow exactly as it was when it ran.
• Deploy — toggling isDeployed exposes the workflow as a stable, callable API surface. Subsequent edits keep the deployed version pinned until you redeploy.

Source

• apps/actana/app/workspace/[workspaceId]/w/[workflowId]/ — editor UI
• apps/actana/blocks/registry.ts — block registry (249 types)
• apps/actana/triggers/registry.ts — trigger registry
• apps/actana/executor/ — run orchestration + per-block handlers
• apps/actana/serializer/ — graph snapshotting for runs
• packages/db/schema.ts — workflow, workflow_blocks, workflow_edges, workflow_execution_snapshots, workflow_execution_logs