Action nodes
Action nodes change the state of the work item a flow is processing. While trigger, utility, and integration nodes move data through the flow, action nodes record the outcome on the item itself so it shows up correctly in monitoring and reporting.
One action node is available today:
- Mark Item as Complete — set the work item's status to complete when processing has finished.
Permissions. Adding and configuring action nodes is part of building a flow, so it requires the Admin or Partner role. See Users and access.
Mark Item as Complete
In the Nodes library this node is labelled Mark Item as Complete.
What it does. Marks the work item as complete, signalling that the flow has finished its work on that item. It can also write custom properties onto the item at the same time.
Status: Available.
When to use it. As the final step on a successful path through a flow — after extraction, validation, any human review, and any write-back to an external system have all succeeded. It is the node that closes out an item.
Prerequisites. A work item must exist in the run. Items are created upstream when files are read into the flow (see Read Files), so Mark Item as Complete is placed after those steps.
Required inputs
- Item ID — the item to mark complete. Defaults to the item being processed in the current run, so you normally don't set it by hand.
- Project ID — the AI Agent the item belongs to (the field name reflects the API's project identifier). Also defaults from the current run.
Configuration fields
- Item Properties — optional custom properties (key–value pairs) to set on the item as it completes — for example, a reference number captured during the flow.
Outputs. The updated work item, which downstream nodes could read if any follow — though in practice this is usually the last node on its path.
Effect on item state. The item moves to the Complete status. Complete is a terminal state: the item leaves the active work queue and is reported as completed. The other item states an item can be in are In progress, Review, and Failed; see Item status reporting.
Placement in a flow. Put it at the end of the successful branch. If a flow has multiple outcomes — for example, items that pass validation versus items routed to Flag for Human Review — complete each path once its work is genuinely done. Don't mark an item complete before a required review or write-back, or the item will report as finished while work remains.
Downstream behavior. Completing an item is typically the end of the line for that item. Nothing needs to follow it, and the completed item appears in Run history and item reporting as complete.
Failure conditions
- The item or AI Agent can't be resolved — usually because no item was created upstream (Read Files wasn't run) or the references weren't mapped. The step fails and the run is marked failed.
- The completion update itself fails at runtime. The failed step is visible in Run history; fix the cause in the draft and re-test before publishing. To rerun programmatically, use the API rerun endpoint.
Example. In Submission Intake, after the submission is extracted, validated, and written back, Mark Item as Complete closes the item so it shows as complete in reporting.
Related monitoring guidance. Track completed items and watch for items stuck before completion in Run history and Item status reporting.
Where to go next
- Node catalog — every node and category at a glance.
- Utility nodes — Read Files, validation, and human review that precede completion.
- Control nodes — branch so each outcome completes on the right path.
- Item status reporting — how completed items are reported.
- Run history — confirm items complete as expected.