Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cogniagent.ai/llms.txt

Use this file to discover all available pages before exploring further.

Every time an application runs, it does so as an execution — a single run of the workflow with its own history of events, node results, and state. Two settings shape how executions behave: the application’s execution mode and the engine’s built-in lifecycle rules that decide when an execution is finished.

​
Execution mode

Open the application settings (the gear icon at the bottom of the canvas) to choose how events are grouped across runs.
Application details with Single Instance and Multi Instance choice
Best for: apps that act like a persistent listener — one Gmail watcher, one webhook receiver, one scheduled poller.All events arrive inside the same running execution. Triggers route to the most recent running execution, so the history, variables, and dispatcher conversations accumulate in one place.Single instance is the default and works well for most automations.
Best for: apps where each incoming event should be tracked separately — one execution per support ticket, per order, per inbound call.Triggers configured to start a new instance spawn a fresh execution for every event. Each instance is fully independent — its own history, its own variables, its own lifecycle.Use multi instance when you want isolated runs you can audit or reproduce individually.
The execution mode is a property of the application, not of an individual run. Switching modes affects how future triggers are routed; existing executions are unaffected.

​
How an execution ends

An execution moves through one of four terminal states:
StatusWhen it happens
completedThe workflow ran to the end of every branch and nothing else can fire.
failedAt least one node errored and no further work was possible.
stoppedYou clicked Stop Execution in the toolbar.
cancelledThe execution was cancelled programmatically (rare; internal use).

​
Auto-stop

The engine watches each execution and stops it automatically when no more work is possible. This keeps the execution list clean and frees up resources — you don’t have to click Stop Execution for every finished run. An execution auto-stops when all of the following are true:
  • Every branch of the workflow has finished running.
  • The graph has no node types that can receive new events later — no triggers, webhooks, scheduled events, portal entry points, dispatchers, or conversation-flow nodes.
  • No queued jobs remain for this execution.
The final status is inferred from what happened during the run:
  • completed — every node that ran succeeded.
  • failed — one or more nodes failed.
Auto-stop runs the same cleanup as manual stop. Pipedream triggers, scheduled cron jobs, channel pollers, and active dispatcher conversations are all released before the execution is marked terminal.

​
Manual stop

Click Stop Execution in the bottom toolbar to halt a running execution immediately. The execution is marked stopped and the engine performs the same cleanup as auto-stop.
Stopping an execution does not undo the work that already happened — emails that were sent stay sent, records that were written stay written. Stop ends the run; it does not roll it back.

​
Viewing executions

The bottom toolbar exposes the execution history and live event log. Click the Execution History icon in the bottom toolbar to open the executions list. Each row is one run of the application, with its status, start time, and duration.
Execution History icon in the toolbar and the resulting executions list panel
Pick an execution to drill into its event timeline — every node that started, finished, or failed, in the order it happened. Filter by Running, Completed, or Error, or search by name to find a specific event.
Events panel for a single execution showing live node-by-node activity

​
Choosing between modes

  • Your app reacts to a stream of events that don’t need to be tracked separately (“notify me whenever a new lead comes in”).
  • You want a single timeline of activity across all events.
  • You want lower overhead — only one execution is ever active.
  • Each incoming event represents an independent unit of work (“process this order from start to finish”).
  • You need isolated history per event for auditing or debugging.
  • Different events should be able to fail independently without affecting each other.

​
Next steps

Run a workflow

Walk through starting an execution end-to-end.

Trigger nodes

See which trigger types can spawn or feed an execution.