What is an ActionFlow?Copy Anchor Link

An ActionFlow is a saved, node-based workflow. It has one supported start node, connected execution and data edges, and nodes that perform AI, integration, data, storage, control, or human-approval work. A run reads the saved graph; the canvas is a way to edit that graph, not the run itself.

The lifecycleCopy Anchor Link

1. Edit the graph in Actionflow Studio.
2. Save the graph. Actionflow Studio saves the current graph before starting a run, and API/webhook callers use the saved ActionFlow data.
3. Validate at the ingress surface. validateFlow checks the saved structure and requirements of nodes reachable from the start node. Actionflow Studio/API rerun and webhook paths call it before enqueue; scheduled dispatch can create a history row without that same pre-enqueue check, and queue-dispatched runs can do so before queue-time validation.
4. Run the full graph from its start node. Actionflow Studio does not execute an isolated node; it runs the complete reachable workflow.
5. Inspect live output, run history, artifacts, and settled credit usage. See Execution model and Run history.

A run consumes organization credits. Actionflow Studio's cost display is an estimate when cost calculation is enabled; the usage record is the settled amount after the runtime calculates billable node and AI usage. See Usage.

Passive and active flowsCopy Anchor Link

New flows are passive. A passive flow remains editable, and Actionflow Studio can be used to configure and test it. Passive is not a graph lock. The current webhook handler rejects a passive flow with 409, and scheduled dispatch only claims active flows. The API/Actionflow Studio runActionFlow path currently does not perform that active-state check, so do not expect a 409 from that path. Set the flow to active in Settings before relying on webhook or schedule triggers.

What the graph containsCopy Anchor Link

• One start node: Start, Start Scheduled, or Start Subflow.
• Connected nodes: AI, communication, integration, data, storage, control, and HITL nodes.
• Execution edges: determine which node can run after another node completes.
• Data handles and mappings: pass a selected output to a named input or resolve {{nodeId.outputPath}} in a saved value.
• Run inputs: empty required fields can be exposed as {nodeId}_{inputName} Flow inputs for the paths that support them; they are ingress-specific and do not replace API/webhook saved-graph validation.
• Control nodes: If, Switch, Loop, Merge, and Wait have the current behavior described in Execution model.
• Status: new flows are passive until activated; activation also recalculates the next scheduled run time.

Inbound HTTP is a flow webhook attached to a Start graph, not a separate start-node type. Chat channels belong to Action Agent triggers, not Flow nodes.

Where to go nextCopy Anchor Link

• Execution model: sequential execution, mappings, control nodes, failures, and history limits.
• Troubleshooting: a numbered path from trigger source to node error.
• Actionflow Studio: save, run, stop, and inspect the full graph.
• Node settings: resolve required inputs, mappings, credentials, and models.
• Node handles: distinguish execution ordering from named data connections.
• Run history: status transitions, reruns, cancellation, and persisted results.
• Trigger: choose the graph's start shape.
• Webhook: configure inbound HTTP delivery.
• HITL approvals: pause and continue a run for human review.
• Artifacts: distinguish generated and uploaded files.
• Settings: active state, metadata, visibility, and plan limits.
• Usage: estimate versus settled credits.