⚙️How Workflows Run
⚙️ When a workflow runs, Wkil determines execution order from its connections: each block starts as soon as the blocks it depends on have finished.
Blocks run as soon as they can
Multiple blocks can run at the same time. A block starts the moment its dependencies finish and waits for nothing else. For example, if both a Customer Service agent and a Deep Research agent depend only on the Start block, neither waits for the other—they run in parallel.
A block waits for all its inputs
When several blocks feed into one block, that block waits for every upstream block that will actually run. It then runs once with all outputs available. An upstream block on a branch that was not taken does not hold it up, and you do not need to merge outputs manually. For example, a Function block runs after both agents finish, with both outputs ready.
Branches take one path
A workflow can split. A Condition follows an explicit rule, while a Router lets the model choose a path. Only the selected path runs. A block on an unselected branch produces no output, so a connection tag pointing to it resolves as empty. To repeat work, a Loop runs its inner blocks over a list, for a fixed count, or while a condition remains true. Parallel runs them for several items at once. A workflow can call another workflow through a Workflow block, an MCP tool, or an API block. Wkil tracks the call chain and stops any run that exceeds the hop limit, preventing workflows from calling each other forever.
When a block fails
A block error fails the run: blocks already running may finish, but no new blocks start. To handle failure instead, connect the block's error port so the run follows an error path and continues.
Run duration
A synchronous run has a time limit, while an asynchronous run receives a longer window. Split work or run it asynchronously to avoid reaching the limit.
Monitoring a run
During execution, the editor shows each block's live status: waiting, running, completed, or failed. Every run is logged, so you can open Logs to inspect what each block received and returned.
💡 For debugging, read the connections to understand execution order, and remember that a tag pointing to an unselected branch resolves as empty.