# Detailed Test Report for Workflow Runs

> The Workflow run layout: sequential node executions, extracted variables, per-node request/response and logs, and why an early failure cascades.

Source: https://totalshiftleft.ai/help-center/product-documentation/detailed-test-report-workflow

## Overview

This is the detailed report for a **Workflow** run. It is a different layout from the [Detailed test report](/help-center/product-documentation/detailed-test-report) used for **Functional** runs, because the thing being reported is different.

A Functional run is a set of independent tests — each one's result stands alone. A workflow is a *sequence*: nodes execute in order, each one potentially depending on values the previous node produced. So this report is organized around the sequence and what flowed through it.

## Execution Summary

The run's metadata:

| Field | What it shows |
|-------|----------------|
| **Run Id** | The run's unique id. |
| **Executed By** | Who or what started it. |
| **Date & Time** / **Execution Time** | When it ran and how long it took. |
| **Execution Type** | Manual or scheduled. |
| **Projects** | The projects involved — a workflow can span more than one. |
| **Priority** | The workflow's priority. |

## Node Executions (Sequential)

The core of the report: each node in the order it executed, with its outcome.

Read this **top down, and stop at the first failure.** In a sequence, the first genuine failure is usually the only real one — everything after it is a consequence. A node that failed because the node before it never produced the id it needed isn't a second bug; it's the same bug, reported twice.

This is why a workflow's **Not run** count is often large and rarely alarming: once the chain breaks, the remaining nodes never get their turn. Compare that with a Functional run, where **Not run** means something was deliberately skipped.

If no nodes ran, the report shows **No node executions found**.

## Extracted Variables

What each node pulled out of its response and passed forward — the mechanism that makes a workflow a workflow rather than a list of requests.

This is the first place to look when a later node fails on obviously wrong input. If a node shows **No Variables Extracted** and a downstream node needed one of its values, you've found the break: the extraction didn't match the response, so the next node ran with nothing.

The failure surfaces at the *consuming* node, but the cause is at the *producing* one. Always walk back up the sequence.

## Request & Response Details

Per node, the request as sent and the response as received. Same discipline as a functional report: check the URL, then the headers, then the body, before suspecting the API.

In a workflow the extra question is whether the values from earlier nodes actually landed. A request still carrying a placeholder, or carrying a stale value from a previous run, points at extraction rather than at the endpoint.

## Assertions

The checks applied at each node, and whether they passed. A node can execute successfully and still fail its assertions — that's a **Failed** node, not an **Error**.

## Execution Logs

Logs for the run, and per node. Where a node has none, you'll see **No execution logs available for this node** or **No detailed logs available for this node**; if the run has none at all, **No execution logs available**.

## Error Summary

The consolidated errors from the run. Useful for a quick read, but for anything non-obvious go back to **Node Executions (Sequential)** and find the *first* failure — the summary lists errors, and in a cascade most of them are symptoms.

## Troubleshooting

- **Many nodes Not run** — normal after an early failure; the chain stopped. Fix the first failing node and re-run before investigating the rest.
- **A node failed on input that looks wrong** — check **Extracted Variables** on the node *before* it.
- **"No Variables Extracted" on a node others depend on** — the extraction didn't match the response shape. Compare against the actual response in **Request & Response Details**.
- **The workflow passes alone but fails in a pack** — likely shared state or ordering. Workflows that depend on data another test mutates aren't independent.
- **"Error Loading Report" / "No report data available"** — the report couldn't be fetched. Reload; if it persists see [Debug logging](/help-center/product-documentation/debug-logging).

## Related articles

- [Detailed test report](/help-center/product-documentation/detailed-test-report)
- [Understanding workflows](/help-center/product-documentation/understanding-workflows)
- [Workflow execution details](/help-center/product-documentation/workflow-execution-details)
- [High level test report](/help-center/product-documentation/high-level-test-report)
- [Creating and running workflows](/help-center/product-documentation/creating-and-running-workflows)