Workflow Concepts

Workflows automate multi-step processes by connecting nodes into an execution graph. Each workflow starts with a trigger, passes through action, condition, and routing nodes, and ends with delivery. Thallus executes the graph by traversing edges from the trigger node, running nodes in sequence or in parallel where the graph allows.

How a workflow runs

A typical workflow follows a linear or branching path from trigger to delivery:

Trigger
Action
Condition
Branch
Delivery

The executor runs nodes following the workflow's defined paths and dependencies. When a node has multiple outgoing edges, it evaluates conditions on each edge and executes the matching branches in parallel. When branches converge at a merge node, the merge waits only for branches that actually executed — skipped branches are ignored.

Node types

Workflows use nine node types, each serving a distinct role in the execution graph:

Trigger
Trigger
⚙️
Action
Action
Condition
Condition
🔀
Router
Router
🔗
Merge
Merge
🔄
Loop
Loop
📄
Subworkflow
Subworkflow
Approval
Approval
📨
Delivery
Delivery

Each type has specific configuration options and execution behavior. See Node Types for detailed documentation on each.

Workflow states

A workflow moves through lifecycle states that control whether it can be triggered:

State Description Can execute?
Draft Being edited, not yet activated No
Active Running on schedule or accepting triggers Yes
Paused Temporarily disabled by user No
Error Auto-disabled due to consecutive failures No
Archived Soft-deleted, kept for history No
✎ Draft ▶ Active ⏸ Paused ⚠ Error 🗃 Archived

When a workflow accumulates consecutive failures, Thallus automatically moves it to the Error state to prevent runaway executions. You can fix the issue and reactivate it manually.

Execution states

Each node execution within a workflow run has its own status:

Status Meaning
Pending Queued but not yet started
Running Currently executing
Completed Finished successfully
Failed Encountered an error
Skipped Branch not taken (condition evaluated false)

An overall workflow execution can also enter Awaiting Approval when it pauses at an approval node.

Workflow state

Every running workflow maintains persistent state throughout execution, storing execution metadata, context, completed node tracking, and individual node results. If a workflow crashes mid-execution, it can resume from its saved state. Approval nodes carry a context snapshot for additional resilience.

Template system

Nodes reference each other's output through templates. The template context includes trigger payload data and all previously executed node results:

{{ trigger.payload.customer_name }}
{{ nodes.research_task.response }}
{{ nodes.data_query.response | upper }}

Templates are evaluated at execution time. The nodes object maps node titles (lowercased, spaces replaced with underscores) to their result objects. Common filters are available:

Available filters
upper lower default tojson truncate replace length trim

Condition and router nodes use the same template context to evaluate their expressions, making it straightforward to branch based on previous node output.

Timeouts and retries

Workflows enforce timeouts at multiple levels to prevent runaway execution:

Level Description
Workflow Configurable total time for the entire workflow
Branch Configurable time for parallel branch execution
Node Individual node timeout (inherits from branch by default)

Action nodes support configurable retry logic with exponential backoff. When retry is enabled, a failed or timed-out node waits for an increasing delay before each attempt. You can configure the maximum number of attempts, initial delay, and backoff multiplier to suit your needs.

If a node has success criteria defined, the system evaluates whether the result meets those criteria after each attempt. A result that fails success criteria is treated as a transient error and triggers a retry if enabled.

Rate limits

Workflow execution rates are limited per organization based on your plan tier. When a limit is reached, the system returns a retry_after_seconds value indicating when the next execution window opens. See Billing & Plans for plan-specific limits.