Debugging basics

Debugging in Flow happens on the same canvas where you build. There's no separate debug view — you run your process, inspect results in the execution panel, and make changes when you spot an issue.

Starten einer Debug-Sitzung

The Debug button in the toolbar runs the process. The execution panel appears at the bottom of the screen and spans populate in real time as each node executes.

The Stop button ends the session explicitly. Any change to the process also exits the debug session automatically.

Refer to The Canvas for a full overview of debug controls and the execution panel layout.

Reading the execution panel

The execution panel has three tabs. Each one answers a different question.

Spans

The Spans tab shows the execution trace — every node that ran, in order, with timing and a success or failure indicator. Selecting a span highlights the corresponding node on the canvas, making it easy to see exactly where execution reached.

Vorfälle

The Incidents tab collects errors that occurred during the run. Each incident names the node that failed and includes the error message. If your process stopped unexpectedly, check here first.

Variablen

The Variables tab shows runtime variable values. Select a span in the Spans tab and the Variables tab updates to show the state at that point in execution. Use this to verify that upstream nodes produced the data you expected.

Identifying failures

After a debug run, each node on the canvas shows a success or failure indicator. The failed node's span in the Spans tab highlights it on the canvas. The Incidents tab shows the error message. The failed node's properties panel shows the full error object in the output section.

The error object includes a message field (human-readable description) and a detail field (technical cause). Start with message because it contains the user-facing failure summary.

Using mock nodes

Mock output lets you test part of a process in isolation. When you set mock output on a node, it skips actual execution and injects your test data downstream instead.

This is useful when an upstream node is slow, requires credentials not available locally, or depends on external systems. Double-clicking the node opens its expanded view, where the mock output can be set to whatever data downstream nodes expect.

Mocking multiple nodes at once lets the debug session focus on a specific section of the process.

Tipps

• Spans first, incidents second. Spans show the full execution picture; incidents show only what broke.
• Variable values reveal data mismatches. Compare the data a node received with the data the next node expected.
• Mocking external dependencies enables faster iteration. Mocking a node that calls an API or triggers an RPA process lets you debug logic without waiting on external systems.
• Small iterations are faster. One fix per debug cycle is more efficient than trying to fix everything in one pass.
• Descriptive node names improve trace readability. Spans and incidents reference node names — names that describe what a node does make execution traces easier to scan.

Zugehörige Seiten

• The Canvas — full debug controls and execution panel reference
• Error handling — configuring error branches on nodes
• Variables and data flow — how variables work across nodes