Skip to main content
The Runs page shows all runs across your organization. You can also view runs for a specific workflow from its detail page.

​
Exporting runs

Select one or more rows, then click Export to download the selected rows as CSV (requires the CSV export entitlement). This is useful for sharing a specific set of runs with a teammate or attaching them to a ticket.

​
Bulk actions

Select one or more rows to reveal the bulk action bar:
  • Cancel: cancels the in-flight runs in your selection. Completed and other already-finished runs in the selection are skipped, so a mixed selection only cancels what can actually be cancelled.
  • Delete: permanently deletes the finished runs in your selection, together with their sub-runs and every step output. In-flight runs in the selection are skipped, so cancel those first and wait for them to finish. The confirmation counts the sub-runs that go with the selected runs, since sub-runs cannot be selected on their own. A run whose output another re-run still uses is kept; delete the re-runs based on it first.
  • Export: download the selected rows as CSV (see above).

​
Filtering runs

Each column header offers a filter so you can narrow the list:
  • Status: a multi-select of run statuses. Pick any combination of Queued, Running, Completed, Failed, Review, Waiting, Cancelled, and Awaiting Sub-runs.
  • Started: a date range over when the run started.
  • Error: search the error text (or filter to runs that have any error, or none).
  • Workflow and Document: search by workflow or document name.
A Dry run badge appears on the status cell for any run started as a dry run, so you can tell preview runs apart from live ones. The run statuses are:
  • Queued: waiting to start
  • Running: currently executing
  • Completed: finished successfully
  • Failed: encountered an error
  • Review: paused for human review
  • Waiting: parked on a Wait node until its timer elapses or its resume webhook is called
  • Cancelled: manually cancelled
  • Awaiting Sub-runs: waiting for child runs from document chunking to complete

​
Run detail

Click a run to view its details. The run detail page shows:

​
Which version a run used

A Ran on v badge near the top of the page names the workflow version this run started on. Click it to open that version on the Versions page, compared against the current saved workflow. A run always keeps executing the version it started on for its whole lifetime, even across a pause for review, a Wait, or a breakpoint. If the workflow has been saved since the run started, the page shows a hint that newer changes exist, so you know the run is not reflecting your latest edits. A run parked for a review, on a Wait, or at a breakpoint offers Restart here on latest, but only once the workflow has been saved since the run started, and only on a top-level run: a park inside a called section cannot be restarted this way, because the parent run still holds the document. It cancels the parked run and starts a new one pinned to the latest saved version, picking up from the parked node, instead of continuing the current run on the version it started on. See the resume rule for the full explanation.

​
Run again

On a terminal run (Completed, Failed, or Cancelled), the header offers Run Again: it re-executes this same run from the start, on the workflow version it originally ran on. Previous step results are replaced, so the run’s history stays a single entry instead of leaving the old attempt behind as a failed run. A dry run’s rerun stays a dry run. This action is only available on a top-level, full run; cancel an in-flight run first.
Run Again replays the pinned version and does not pick up workflow edits. To process the document with the workflow as it stands now, use Trigger Run on the workflow’s documents table, which starts a new run on the current version.
If a callback, Business Central, or QuickBooks node in this run already reached its destination, the rerun is refused with a second dialog naming that node and when it sent. Check the destination before confirming: the rerun sends again and creates a second record there.

​
Step timeline

A visual timeline of each workflow step and its status. Steps are shown in run order with timestamps. Each step in the navigator shows the node type, with the configured node name beneath it when the name differs from the type label. Use the Show skipped toggle in the navigator to show or hide steps that were skipped during this run. A step that executed inside a sub-run (for example, a Loop body node) shows an Open sub-run #N link in the output panel instead of an empty “Step is pending/failed” panel. The link deep-links to that child run. On a terminal run (Completed, Failed, or Cancelled), hovering a step in the navigator reveals a Re-run this step button (circular-arrow icon). Choosing it opens a confirmation (“Re-run this step and re-execute all downstream steps from this point. This may consume credits.”) and starts a new run from that point. The new run inherits the mode of the run it restarted: restarting a live run sends for real, and restarting a dry run stays a preview.
If a callback, Business Central, or QuickBooks node below the step you picked already reached its destination, the re-run is refused with a second dialog naming that node and when it sent. Check the destination before confirming: the re-run creates a second record there.

​
Step data

Click a step in the timeline to inspect:
  • Input: data received from the previous step
  • Output: data produced by this step
  • Errors: error details if the step failed
  • Timing: start time, end time, and duration
  • Credits: credits charged to this step
  • Skip reason: when a step was skipped, a brief explanation of why (for example, the step was bypassed by a route condition)
  • Empty references: an amber banner reading “N references rendered empty on this step”, listing the exact tokens that resolved to nothing
The empty-references banner appears on workflows with strict references turned off, where a reference that finds nothing renders as an empty string and the run carries on. It is how you spot a hole before the system receiving the data does. On a step that already failed under strict references, the banner drops the “turn strict on” hint, because the failure lists those same tokens. A Loop body step shows one array-shaped output that you page through per item with the Item pager in the Output header. When a Loop node’s If an item fails setting is Continue with remaining items, the loop step shows an N failed badge and the list of item errors whenever at least one item failed, and the per-item pager on a body step marks each failed item and shows its error.

​
Waiting step

When a step is a parked Wait node, its panel is read-only and shows what the run is waiting on: the mode, and when (or on what) it resumes. There is no action to take here, because a timer or a webhook is what moves the run forward. In webhook mode the panel also shows the deadline the step fails at if nobody calls back, and the Resume webhook URL with a copy button. Hand that URL to the system you are waiting on.
Treat the resume URL like a secret. Anyone holding it can resume that run.

​
Reconcile preview

When a step is a Reconcile node, its Output / Preview tab shows a side-by-side comparison of Source A versus Source B with a summary header (for example, “Within tolerance” or a badge of N blocking mismatches alongside a warnings badge).
  • Compared header fields render as a Field/Values table.
  • Line-item rules render as a Line items table, with one row per matched line plus banners for rows present in only one source.
Blocking mismatches appear in red and warnings appear in amber. Each source value is tagged with a colored dot. Arrow keys move the selection through the table. A Reconcile step compares values that earlier steps produced, so its cells do not highlight the document; open the Extract step that produced a value to see where it was found.

​
Document viewer

For runs with extraction results, the document viewer renders the source document beside the extracted fields and supports:
  • Bounding box overlays: colored rectangles show where each field was found. When a value spans multiple lines, each line gets its own rectangle so the highlight tracks the actual text rather than a single bounding box that covers unrelated content.
  • Field info popovers: hover any bounding box to see the field name, the extracted value, and the confidence score.
  • Contested bindings: a dashed rectangle marks a value that is printed more than once in the document, where the highlight could have landed on another copy. Select the field to outline the copies it was not bound to. See contested bindings.
  • Rotate: if a scan came in sideways or upside down, use the rotate control in the viewer toolbar to spin the page 90° at a time. The rotation is local to your view; the source document is not modified.
Office and CSV documents are converted to text rather than rendered into pages, so the viewer shows the converted text with no overlays, no popovers, and no rotate control. Use Download original to open the source document in its own application.

​
Dry run previews

On a dry run, output nodes show previews instead of sending real outputs.
  • Callback steps show the resolved URL, request headers, and request body preview
  • Email steps show the recipients, subject, body preview, and attachment names
Each step’s Output panel offers a Preview tab (a structured, human-readable view) and a Raw tab (the full JSON output).
Dry run previews help you verify output configuration before you send live outputs.

​
Copy run for an LLM

From a run detail page, open the command palette (Ctrl+K) and run Copy for LLM to copy the run as markdown. You can choose which sections to include:
  • Summary
  • Steps
  • Step inputs
  • Step outputs
  • Errors
Sections that are unavailable for the run are disabled. The copied markdown is meant to paste into an AI assistant. See Keyboard shortcuts for more on the command palette.

​
Callback Delivery History

If the workflow includes a Callback output node, the run detail page shows a Callback Delivery History panel. A delivery outcome banner at the top summarizes the final attempt: a Delivered or Failed label, the final HTTP status code badge, the total attempt count, and the last attempt latency. Below the banner, the attempt list is ordered newest-first, with the latest attempt expanded by default. Each attempt row shows:
  • Attempt number
  • HTTP method
  • Status code
  • Latency
  • Relative timestamp: hover to see the absolute time
  • Target URL
  • Error message: shown if the attempt failed
Expanding an attempt reveals collapsible Request Payload, Request Headers, and Response Body panels, each rendered as read-only JSON. The panel shows an empty state when there are no attempts to display:
  • When the callback step failed before delivering, a Callback did not run banner shows the step error.
  • When the step completed but no delivery was needed, the panel shows “No delivery was needed.”
  • Otherwise, the panel shows “No callback delivery attempts yet.”
For a dry run, the panel shows the prepared-request preview (method, resolved URL, headers, and JSON body) instead of an attempt list.

​
Run actions

The actions menu on each run row offers:
  • Go to Workflow: navigate to the parent workflow
  • Download Output: download the captured payload. Only available when the run has a completed Download output step. This action is run-scoped: if the workflow has more than one download output, it serves the last one the run reached. To download a specific node’s output, open the run and use the Download button on that step
  • Cancel Run: stop a run that is in flight (running or queued)
  • Delete Run: permanently remove a run and all of its sub-runs, including every step output. Only a top-level run that has reached a terminal state (completed, failed, or cancelled) can be deleted. Cancel an in-flight run first. A run that is still referenced by another run (a partial re-run based on its outputs) cannot be deleted until the dependent runs are removed

​
Testing from the editor

You can start a run directly from the workflow editor.
  • Select a document from the run toolbar
  • Use documents in Uploaded, Completed, or Failed status
  • Choose Dry run for preview-only outputs or Live run for live outputs

​
Workflow timer

When viewing a run in the workflow editor, a timer badge appears in the top-right corner of the canvas:
  • Running: a blue badge shows elapsed time, updating in real time
  • In review: an amber badge indicates the run is paused for human review
  • Completed: a green badge shows the total processing time
  • Failed: a red badge shows the time elapsed before the failure

​
Child runs

When a document is split into chunks, each chunk is processed as a separate child run. Child runs appear as expandable rows in the runs table: click the expand icon on a parent run to see its child runs inline. In the run detail view, use the sub-run navigator to page through sibling child runs without returning to the table. The navigator shows the current child run’s index and lets you step forward or backward through the set.

​
Real-time updates

Run status and step progress update in real time via SignalR. Both the runs list page and the run detail view receive push updates, so you see changes as they happen without refreshing the page.