Testing & Debugging

You test a workflow by running it and inspecting the data each step produced. The tools for both live on the canvas.

Running a Workflow

A manual run starts from a run point. Every workflow has one: Glow picks the first eligible step for you and marks it on the canvas, so Run always has somewhere to begin.

To move it, right-click the step you want and choose Set run point. Or open the arrow beside Run in the dock and pick from the Manual run starting step list.

Where you put it is a real choice:

• On the trigger to exercise the whole workflow end to end, using the trigger’s test data.
• On a step in the middle while you are building, so you skip the steps before it. Handy when the earlier ones are slow, cost money, or send real messages.

Glow prefers a trigger for the automatic run point. Add a trigger later and the run point moves to it. A step you chose yourself keeps the job until it is deleted or disabled; then Glow picks again. A disabled step cannot be the run point. Enable it first, or pick another step.

The run uses whatever Testing data the run-point step holds. A run is only as realistic as that data. Load latest execution in the step’s Test & Debug tab fills it from a real run.

Running a single step

Hover a step and two controls appear on it:

• Run: on a trigger, this tries to fetch live data from the service it watches. On an action step it executes the step.
• Run with test data: uses the step’s saved Testing data instead of going out to the network.

The distinction matters on triggers. A trigger that has not finished deploying cannot poll for live data yet. Glow tells you so and points you at Run with test data, which works immediately and is usually what you want while building anyway.

On-Canvas Setup Checklist & AI Repair

When building or testing a new workflow draft, the Setup Checklist sits directly on the canvas to track your progress:

• Connecting required app accounts
• Providing valid test trigger payloads
• Running single-step tests
• Publishing the workflow

AI Debug Automation (“Use AI to fix”)

If an assistant-generated draft or imported workflow fails validation (such as missing a trigger, broken port links, or unbound variable chips), the checklist displays a Use AI to fix button.

Clicking it runs an automated diagnostic pass:

1. Identifies structural flaws: Scans for orphaned steps, missing inputs, and broken type chains.
2. Repairs canvas geometry and connections: Rewires broken links and aligns data sources automatically.
3. Supplies reasonable defaults: Configures missing test values so you can run an instant verification test.

Inspecting data with Executions

When debugging a failing workflow, the best approach is to work backwards from the point of failure.

In the Executions tab, you can view the exact JSON payload each step produced. What a step received is the output of the step above it — read it on that step’s own Executions tab.

Visual step statuses

While a workflow runs, each step changes colour to show where the run has got to and how each step finished. You can follow a run on the canvas without opening the execution log.

Hover a step after a run and its tooltip tells you how it ended:

Tooltip	Colour	What it means
Execution in progress	Blue	The step is still running. You will see this longest on steps that wait on somebody else, such as an HTTP Request.
Execution succeeded	Green	The step finished and passed its output to the next one.
Execution failed	Red	The step gave up: a 500 from an API, bad credentials, or a workspace out of credits. Unless the step is set to continue on failure, the run stops here.
Execution issue found	Amber	Something went wrong without sinking the step. Typically some items in a loop failed while the rest succeeded.
Execution skipped	Grey	The step did not run, usually because a Condition or Switch sent the run down a different branch.

Running out of credits shows as Execution failed, the same as any other failure, so the tooltip alone will not tell you which one you are looking at. The note below covers what to check.

The numbers on a step

Alongside the status, a step carries small counters summarising its history. One shows how many times it has run. When retries are configured, a separate marker shows the retry count. They are a quick read of which step is doing the most work, or failing the most often, without opening anything.

Clear them with Reset counters from the canvas utilities menu once the numbers have stopped meaning anything.

Debugging code and HTTP steps

If you are using Code editor or HTTP Request steps, they carry their own debugging aids:

• Use print() in a Code editor step to see intermediate values. The step runs Python, and whatever it printed comes back under result.executionOutput. Reference it as {{ 4.result.executionOutput }}, or read it in the step’s Executions tab.
• Inspect raw HTTP response headers and status codes directly in the drawer.

What’s Next?

• Follow a whole run, step by step, in the Execution Log.
• Dig into the input and output payloads of a single step in Step-level Executions.
• Look up an error message you cannot place in Troubleshooting & Errors.