Automation
Node reference
Reference every Workflow Studio node type and when to use it.
This is the canonical node catalogue for Workflow Studio. Object workflows, ticket workflows, and document workflow studio all point here — node behaviour is shared even when binding differs.
Backend types live on workflow.NodeTemplate (NodeTemplateNodeTypes). Templates store nodes_json / edges_json; published versions are what runtime executes.
Catalogue
Start (startNode)
Entry marker for the canvas. Always begin human-readable graphs here. Does not itself listen for events — pair with a Trigger on object workflows.
Trigger (triggerNode)
Available on object workflows and scheduled workflows. Starts the graph from a model event or a recurrence. Configure trigger_namespace, trigger_event, trigger_is_periodic, and trigger_data. See Triggers & events.
On a scheduled workflow the trigger is always periodic and has no namespace or event to choose — only a recurrence.
Task (taskNode)
Creates human work: title, content, duration, team/assignee rules, optional questions, notifications, completion state. Use when a person must act. Can schedule relative to record times via anchor/timedelta fields.
Decision (decisionNode)
Binary (or meta-driven) branch. Evaluate decision_meta and follow yes/no parent paths. Keep conditions explicit and testable; prefer named fields over opaque expressions.
Approval (approvalNode)
Formal sign-off using approval_data and assignee rules. Distinct from a Task: approvals track approve/reject semantics used across tasks, documents, and workflows. See Approvals.
Action (actionNode)
Deterministic platform operation via action_meta — model consequences, field updates, notifications, or other configured actions. Prefer Action over Script when a built-in consequence exists.
Iris Agent (agenticNode)
Runs Iris with agentic_data (prompt, topic, expectations). Use for classification, summarisation, drafting, or tool-using reasoning inside a process. Pair with Tools when the agent must call platform tools. See Iris in automation.
Tools (toolsNode)
Supplies tools_data to a parent Iris Agent. Validation expects an agent parent. Keep the tool allowlist minimal for the step.
Script (scriptNode)
Runs script_data as a workflow step. Same family as object scripts / Scripts API. Use for custom transformations that Actions cannot express. Test in the playground.
Route (routeNode)
Assignment or path selection from route_data (teams, rules, attributes). Use when ownership depends on configurable routing rather than a fixed assignee.
Delay (delayNode)
Pauses using delay_data (fixed or calculated). Use for cooling-off periods, SLA waits, or “remind in N days” paths.
Loop (loopNode)
Iterates a branch from loop_data (items or controlled retry). Guard loops with clear exit conditions to avoid runaway jobs.
Sources: object (Dynamic Object records), csv (a comma-separated directive, interpolated), array (an upstream Iris agent's result buffer), memory (an agent's stored memory).
The current item is published on the run context under the loop name:
{{workflow_context._loop.<loop_name>.instance}} record sources
{{workflow_context._loop.<loop_name>.value}} csv, array and memory sourcesLoop data is ephemeral — read what you need through the merge keys while the loop is running, because it is discarded once the node finishes. Fan-out is capped by your plan tier; see Workflow limits.
Filter (filterNode)
Fetches data as configured in filter_data, publishes it onto the workflow run context, and then runs every downstream node once per record found — exactly like a Loop.
The difference is where the data comes from. A Loop's record source is limited to Dynamic Objects; a Filter can read any tenant-scoped namespace — hcm.Employee, tasks.Task, finance.Invoice, objects.Lead — which makes it the natural first step of a scheduled workflow that has no record behind it.
Configure:
| Setting | Purpose |
|---|---|
| Filter name | Labels the fetched data on the run context — this is the key you merge against |
| Source | Namespace records, Dynamic Object records, comma-separated values, agent result buffer, or agent memory |
| Namespace | The namespace to read, for the two record sources |
| Filter | A Q-notation filter, interpolated at runtime so it can reference the trigger instance or an enclosing loop/filter |
| Ordering | Optional sort field; prefix with - for descending |
| Maximum records | Optional cap, applied under the tier ceiling |
Every pass publishes a deliberately verbose entry so you can label and reuse the data without a second query:
1{{workflow_context._filter.<filter_name>.instance}} current record
2{{workflow_context._filter.<filter_name>.value}} current item (same as instance for record sources)
3{{workflow_context._filter.<filter_name>.index}} zero-based position
4{{workflow_context._filter.<filter_name>.position}} one-based position
5{{workflow_context._filter.<filter_name>.count}} how many records were found
6{{workflow_context._filter.<filter_name>.first}} true on the first pass
7{{workflow_context._filter.<filter_name>.last}} true on the final pass
8{{workflow_context._filter.<filter_name>.results}} the full result setLike Loop data, this is ephemeral. If the filter finds nothing, the branch below it simply does not run.
Escalation (escalationNode)
Applies escalation metadata when time, state, or ownership rules are breached — typically after tasks/approvals stall.
End (endNode)
Terminal path. On ticket forms, entering End closes that ticket path. Always terminate every branch explicitly.
Legacy: Form (formNode)
Older graphs may still contain Form nodes; treat as Task-equivalent when migrating.
Workflow limits
Workflow usage is metered against the workspace plan. Counters live on the monthly usage record (calendar month, keyed to the 1st) and are reviewed at /settings/account/usage. See also Usage & logs.
There are three tenant-wide ceilings, plus a per-node fan-out clamp for Loop and Filter.
1. Active template versions (snapshot)
How many published workflow template versions may exist at once across object workflows, ticket workflows, and scheduled workflows. Draft / unpublished versions do not count. This is a stock limit — it is recalculated from the database, not reset each month.
| Tier | Active published versions |
|---|---|
| Community | 5 |
| Small | 10 |
| Grow | 25 |
| Enterprise | Unlimited |
2. Workflow runs (monthly)
How many times a workflow graph may start in the current month. Counted once when the trigger fires — before any Loop or Filter fan-out.
Each of the following counts as one run:
- An object / event-driven workflow starts
- A ticket workflow starts
- A scheduled (cronjob) slot fires
- A manual Run now on a scheduled workflow
Nested Loop / Filter fan-out does not create extra runs; that work is Node Executions (below).
| Tier | Workflow runs / month |
|---|---|
| Community | 500 |
| Small | 5,000 |
| Grow | 50,000 |
| Enterprise | 1,000,000 |
3. Node Executions (monthly)
How many times the engine may process a node in the current month. Entering a node once = one Node Execution.
Example: a Filter finds 1,000 records and has one downstream Action → that Action contributes 1,000 Node Executions (plus the Filter’s own execution). Nested Filters multiply the same way, so this monthly pool is what stops pathological fan-out from stalling workers.
| Tier | Node Executions / month |
|---|---|
| Community | 10,000 |
| Small | 100,000 |
| Grow | 1,000,000 |
| Enterprise | 25,000,000 |
Enterprise Node Executions stay finite on purpose — even when active versions are unlimited.
Per-node fan-out (Loop and Filter)
Separately, Loop and Filter share a ceiling on how many items a single node may fan out over in one invocation:
| Tier | Maximum items per node |
|---|---|
| Community | 100 |
| Small | 1,000 |
| Grow | 10,000 |
| Enterprise | 100,000 |
An override can be set per workspace where a plan needs headroom. An absolute backstop of 100,000 always applies — no single node can fan out further, even on an “unlimited” override. Anything beyond the ceiling is not processed, so narrow the query rather than relying on the cap.
Per-node fan-out and monthly Node Executions work together: the node clamp bounds one step; the monthly pool bounds total work across the tenant.
Choosing quickly
| Need | Node |
|---|---|
| Auto-start from create/update/schedule | Trigger |
| Human work | Task |
| Formal sign-off | Approval |
| Yes/no split | Decision |
| Built-in platform op | Action |
| Custom code | Script |
| AI reasoning | Iris Agent (+ Tools) |
| Wait | Delay |
| Iterate over data you already have | Loop |
| Go and fetch data, then act on each row | Filter |
| Reassign / escalate | Route / Escalation |
| Finish | End |
Shared fields
Most nodes have name, description, type, ordering, parents, and canvas position. Human nodes may attach questions. Versioning: edit a draft template, publish one active version per group.