ActionFlow Requirements
The current ActionFlow validation surfaces, reachable-node checks, required inputs, and API versus webhook status codes.
ActionFlow requirements
ActionFlows has more than one kind of requirement feedback. The Actionflow Studio Flow Requirements panel, the server-side validateFlow function, and the API or webhook response are related but not interchangeable.
Requirement feedback is not a static type checker. It can show that a required value, credential, model, or enabled node is missing without proving that every runtime value has the expected shape.
Flow Requirements and validateFlow
| Surface | What it does | What it does not do |
|---|---|---|
| Flow Requirements in Actionflow Studio | Builds live credential presence/readiness for canvas-connected nodes, shows missing provider or integration connections, and opens the add-connection flow. | It is not the full server validator, does not deeply validate object values, and does not test secret validity, SMTP delivery, OAuth scopes, or provider health. |
validateFlow | Validates graph structure and requirement presence on the server, including reachable enabled nodes, present/resolvable credential records, AI model selection, required input presence, and Loop configuration. | It does not prove every data type, execute a node, validate secret contents or an OAuth token with the provider, or guarantee that a later node result exists. |
| REST or webhook ingress | Calls validateFlow at a surface-specific point and maps its result to that surface's HTTP response. | The response contract is not shared: REST uses 400; the flow webhook uses 422. |
The current Actionflow Studio panel focuses on credentials. Treat missing required inputs, disabled catalog rows, malformed graph JSON, and model errors as separate diagnostics even when the panel has no red credential row. Credential validation checks that the relevant record is present, resolvable, and associated with an enabled integration; it does not verify the secret contents or contact the provider.
Only reachable nodes
After validating the overall nodes and edges arrays, validateFlow follows outgoing edges from start nodes that have at least one outgoing connection. The connected set is directed from the start; a node with no path from a start is not checked for enabled status, credentials, model selection, required inputs, or Loop configuration.
A disconnected node can remain on the canvas while the flow is edited. It does not run. The graph's basic structural arrays and records are still validated, so a malformed node or edge object is not made valid merely because it is unreachable.
What validateFlow checks
For the saved FlowData shape, the current checks are:
nodesandedgesare arrays; each node has an ID, type, and data object, and each edge has an ID, source, and target.- At least one supported start node exists.
- When non-start nodes exist, a start node has an outgoing connection and only one start node is active in that graph shape.
- Nodes reachable from an active start are enabled. Their category and linked integration must also be enabled.
- A reachable integration node has a present and resolvable organization credential or OAuth connection when its catalog integration requires one.
- A reachable AI node has an enabled platform model, or a selected service/model with a present and resolvable provider credential for BYOK.
- Reachable regular nodes have their visible required inputs satisfied by a saved value or, for handle-backed fields, a matching named target edge.
- Reachable Loop nodes have a valid output mode and valid manual or inherited item configuration.
Warnings are returned separately. A warning does not make validateFlow invalid; an error does.
validateFlow is not a publish, browser-compatibility, or rate-limit lint pass. It also does not currently enforce the legacy 50 MB, 1,000,000-character, or 10,000-item claims found in older node copy.
Required inputs and Flow input keys
A required field can be supplied in the saved graph, mapped from a named data edge, or collected for a run as a Flow input. Actionflow Studio exposes reachable required fields that are not already saved under:
{nodeId}_{inputName}The Actionflow Studio Manual Try path merges entered values into the node inputs and persists the graph before it calls POST /api/runs; the REST route validates that persisted saved graph. The public template Try path is separate: it applies allowlisted values to an execution copy, validates the copy, and does not persist those values into the template. Backend REST and flow-webhook requests call validateFlow on the saved graph before they merge request inputs and the trigger envelope. A request value therefore does not bypass a saved-graph required-input error on those pre-enqueue surfaces.
An untargeted node-to-node edge establishes order and exposes the source result under its source-node ID. It does not satisfy a required input whose catalog definition uses a named target handle.
API and webhook validation responses
| Surface | Validation timing | Current failure response |
|---|---|---|
| Actionflow Studio Flow Requirements | Live canvas state | No HTTP status; the panel displays credential requirements. |
| Actionflow Studio Manual Try | Entered values are merged into the graph and persisted, then the REST run validates the persisted graph. | The REST validation error is returned to the run surface. |
| Public template Try | Allowlisted values are applied to an execution copy, then the copy is validated; the template is not updated. | A validation result is returned to the public run form. |
POST /api/runs | The saved graph is validated before payload.inputs and payload.trigger are merged. | 400 with validationErrors and validationWarnings for graph validation. |
| Flow webhook | The saved graph is validated before the JSON body and trigger envelope are merged. | 422 with errors and warnings; no run is enqueued. |
| Queued run | The queue consumer validates the saved graph before dispatching to the execution service. | The admitted queue/history item can be marked failed after validation. |
The webhook's 422 is specifically a pre-enqueue saved-graph validation response. It is not the REST endpoint's 400 contract, and an accepted 202 only means that the request was dispatched or queued. A later node or provider failure can still occur.
Active state is separate
validateFlow does not decide whether a flow is active. A passive flow can still be edited and can be used by Actionflow Studio Manual Try. The current flow webhook rejects a passive flow with 409 before validation and enqueue. The REST and Actionflow Studio run path does not currently return the same active-state 409; set a flow active before relying on webhooks or scheduled triggers.
The active-flow count from the organization's CMS plan can prevent activation. That plan check is separate from graph validation. See Settings and Organization permissions.
Related
Usage & Cost
Separate ActionFlow estimates from settled credits, identify hard runtime limits, and label CMS plan settings by their actual enforcement.
Knowledge Base
Organization Knowledge Base collections hold uploaded documents. Action Agents and catalog AI language-model nodes can search them at runtime.