Managing Workflow Runs

When a workflow action inside a Process Flow fails, gets stuck, or needs to be re-run after a fix, the platform gives you controls directly on the Process view card — and in the Logs view for standalone runs.

Viewing a failed run

When a workflow action reaches a terminal failed state, the action card in the Process view shows:

• An inline failure summary — the output.reason string and any per-block errors collected from the run's trace spans.
• The tile's Details button opens a card over the tile's top-right corner (Esc or × closes it). Its Workflow section shows the run's status, the linked workflow, and the workflow drawn with its block and connection count; each block that ran is marked with its outcome.
• An "Open full run" button (canvas-backed actions only), located in the card's Workflow section, that opens a side panel showing the full block-level trace, per-block error messages, and timing — without leaving the Process view.

The "Open full run" button is only shown for canvas-backed actions (system-agent steps @system/… have no canvas run to open). Opening the panel requires only read access.

Cancelling a stuck run

A workflow action that is executing — including one parked on a Human-in-the-Loop (HITL) approval gate — shows a "Cancel run" button on the action card. Clicking it opens a confirmation dialog; confirming sends a cancel request to the server.

What happens on cancel:

1. The platform stops the running workflow immediately, including any approval gate it is parked on — a HITL-parked run is fully stopped, not left in limbo.
2. The run is recorded as cancelled in the Logs view; the run and its approval gate are cleaned up.
3. The workflow action on the Process card is marked failed with output.reason = "Cancelled by <user>". This is the terminal state that also enables the Rerun button.

The "Cancel run" button is visible only while the action is in_progress. It is not shown for completed or already-failed actions.

The Logs view cancel is also fixed. Prior to this release, cancelling from the Logs view did not fully stop an in-progress run; it now behaves identically to cancelling from the Process view.

Rerunning a workflow action (Process view — in-place)

When a workflow action is in a terminal state (failed, completed, or skipped), the action card's Workflow section shows a "Rerun" button. Clicking it re-dispatches the action in place against the same Process Flow instance:

• The previous output, content, and execution id are cleared.
• The action status resets to pending.
• The platform re-dispatches the action through the same path used for automatic stage-entry dispatch, so all the same grounding, retrieval, and output-surface logic runs again.

This is the right choice when the workflow failed due to a transient issue (missing extension config, a flaky external call) or when you have fixed the root cause and want to re-run without starting the whole process over.

Rerunning a workflow run (Logs view — fresh run)

In the Logs view, a terminal run shows a "Rerun" button in the run-detail sheet header. This creates a fresh standalone run using the prior execution's stored input:

• A new execution id is minted.
• The run is scheduled as a fresh instance with the same input data from the original run.
• The new run appears as a separate row in the Logs view and can be inspected independently.

This is distinct from the Process-view rerun: it creates a new top-level run unattached to the process action's state. Use it when you want to re-execute the workflow standalone for diagnostic or testing purposes, or when the original run was started from the Logs view rather than a process action.

Which rerun to use

When an earlier step changes

A step that read another step's output can fall behind it. That happens when someone edits a completed document or list, adds or removes a file on a completed upload step, regenerates a document, applies a refinement, or edits an AI step's output. The steps that read it, directly or through other steps, then show Out of date in the Wizard rail. Ticking a checklist item or deciding an approval does not count as a change.

When you save such a change in the Wizard and at least one later AI step has already run on the old input, the platform asks Re-run the steps this changed? and says how many of those AI steps would run again with the new inputs. It also says how many it leaves alone: steps a person owns, and steps that have not finished a run yet. Only AI steps are re-run; a distribution is never re-sent by an edit. When there is nothing to re-run, for example on the first upload of a run, nobody is asked. Your edit is saved either way: Cancel keeps it and re-runs nothing, and those steps stay marked out of date until they run again.

Reading a Document action's output

document actions let you write or Generate with AI (then Regenerate) the document body. The content is authored in Markdown, but you rarely want to read it as raw Markdown — headings, lists, and tables are hard to scan, and pasting the source into a tool that doesn't understand Markdown (e.g. Outlook) carries the #, *, and | characters across.

Each Document action card therefore has an Edit / Preview toggle:

• Preview (the default whenever the action already has content) renders the Markdown into a clean, styled document — the same renderer used for AI agent output. This is the view to read from and to copy-paste rich text into email or a document editor. A single line break is kept, so a record typed one fact per line (**Date:** under **Performed by:**) reads line by line, as it does in Edit. A blank line still starts a new paragraph. Raw HTML in the text is shown as text, never run.
• Edit opens the same live-preview Markdown editor used in the knowledge base: headings, bold, lists and tables render as you type instead of showing raw #, * and | characters. Selecting text (or placing the cursor on an empty line) reveals a formatting toolbar with bold, italic, strikethrough, inline code, headings, lists, quote, link and table — so you never have to know Markdown syntax to format a document.

Clicking Generate with AI or Regenerate switches to Preview automatically once the result is ready, so you see the finished document styled rather than as Markdown source. An empty action opens in Edit so you can start writing straight away.

Reading and discussing output in the Wizard

The Wizard keeps the stage/task rail on the left, the active action in the center, and the step's Cortex conversation on the right. On narrower screens the conversation moves into a sheet so the action remains readable. The action header shows the action type as an icon (hover it for its name), the title and the status. The line under the title shows Optional for a step that may still be skipped, the owner's avatar (hover or focus it for their name), and an (i) that says what the task asks for when you hover or focus it: the step's description, or else what its type of step is for. Statuses read the same everywhere: green for Completed, amber for In progress and Awaiting approval, red for Failed and Declined. A stage heading in the Wizard's step list, the Kanban and the List says when the stage was completed when you hover or focus it, for example Completed 26 Oct.

A step the author marked optional (isRequired: false) shows Optional in its header and Skip until someone starts it. On a distribution step Skip stands beside Send; on every other step it sits on its own row under the panel, with the note This step is optional. Skipping settles the step without doing it, so an optional email with nothing to say no longer holds its task open; the next task opens as soon as every action of the task is settled. A required step offers no Skip, and the API refuses to skip one (required_action_not_skippable, HTTP 409).

An assignee is shown with the role they hold, for example Lisa De Mol · Security Lead, on the Kanban card, in the list, in the task byline and on the action header. One person can hold several roles in a flow, and the role says which one a step is for.

A task with several actions is walked one action at a time:

• The rail shows each multi-action task's progress, for example 1/3. Under the current task it lists the task's actions, with a check for each completed one. Pick an action there to open its card and scroll to it.
• A completed action shows a green check on its card header, so a folded card still says it is done. The task byline shows the same count, for example 1/3 completed.
• A task opens on its first action still to do. Completing an action folds its card, opens the next action still to do, and moves the Cortex conversation to it. You can still open or fold any card yourself.

Use the Cortex conversation to ask follow-up questions about the current action and its governed knowledge. Its header says which task and step it is about. An empty conversation opens with Cortex greeting you by first name and three starter questions for the kind of step (a document, an approval, a form or checklist, a workflow, or any other step); click one to send it as your own question. The input starts three lines tall and grows with what you type, up to about 40% of the screen. Each answer lists its sources under it, and the book button beside the input lists every source the conversation has cited. Everyone currently authorized for the action sees the same thread, as the line under the input says. Asking a question does not alter the output; on eligible AI answers, Apply as refinement is a separate explicit action that reruns the refinement path.

The conversation also knows the flow's earlier completed runs in the same workspace environment — by default the five most recent. Their closing summaries are part of every answer's context, so a question such as "what did we decide in previous meetings?" is answered from those runs and cites them, and a knowledge search also covers their pages; a result from an earlier run names that run. Runs that are still in progress are never included, and a summary classified above the conversation's clearance is left out. The flow's author sets how many runs are carried over with knowledge.priorCycles.

Workflow, Document, and Assessment output offers a Focus view for full-page reading. Use A− / A+ to adjust the text size, and press Escape or go back to return to the same Wizard position. Grounded AI output includes a References section whose links are authorized when opened; an inaccessible or deleted source is shown as unavailable.

The bottom bar is docked at the foot of the view, in the same place in the Wizard, Kanban and List, and stays there while the step scrolls above it: the step counter (Wizard only, for example 3 / 20), the step's own buttons, ← for the previous step, and Next step. It always fits on one line: when it gets narrow, the step's secondary buttons (Regenerate, Improve with Cortex, Skip) show only their icon, with the name on hover, and then the counter is hidden. In the Wizard, drag the grip between the tile and This step to make the tile wider or narrower; the width is remembered. A Kanban card shows the step's state, its name, its owner and its status, with a handle to drag it to another stage; the List starts with the columns Task, Steps (for example 1 / 3), Owner, Due and Status. Columns, next to Sort and Filter, adds Stage, Step type, Entity, Completed and Re-opened, hides a column or changes their order (Task is always shown). Drag a header's right edge to resize a column, or double-click it to fit the widest cell; Reset columns and widths goes back to the default. The choice is kept per process in your browser. In the Kanban and List views an opened card shows the same step in a sheet over the board, which is dimmed behind it. Close it with Close (Esc), the Esc key, or a click on the dimmed board; focus goes back to the card you opened. Its left edge can be dragged the same way.

A step that was sent back carries a Re-opened ×N tag next to its status in the step tile, on its Kanban card and in its List row, and ↺ after its name in the Wizard's step list. Its tile opens with a Returned for revision box saying when, by whom, why, and what to do. A skipped task or step shows a grey circle with a skip arrow and Skipped where its status goes; hover or tap Skipped in This step to see who skipped it and when. A due date reads Due 2 Nov: grey while there is time, amber in the last two days, and red as Overdue · 2 Nov once past, with a red dot after the task's name in the Wizard's step list. A completed or skipped task is never shown as overdue.

On a wide screen (1280 px and up), the Cortex button stands right of the bottom bar, so it never covers the step (in the Kanban and List, right of an open card's bottom bar). Click it to open the conversation beside the step, and × to close it again; open or closed is remembered for all three views. The button carries a small mark when Cortex has questions for the step. The first time you open a flow, Cortex introduces itself once above the button; any click closes the introduction, and it does not come back for that flow. On smaller screens Cortex opens from the Ask Cortex button in the title bar.

When a run counts as finished

A Process Flow run is Not started, In progress, On hold, Cancelled or Completed. These rules decide when it becomes Completed:

• A live run completes itself. When the last stage of a run that is Not started or In progress finishes, the run becomes Completed. Its completion time is when that work finished.
• On-hold and cancelled runs are never completed automatically. If the last open step settles while the run is on hold or cancelled — a workflow that was still running, for example — every stage can show as done while the run stays On hold or Cancelled. Putting a run on hold or cancelling it is a decision the platform does not override.
• Resuming a run whose work is all done completes it. When an on-hold run is set back to In progress (or Not started) and every stage has already finished, it becomes Completed straight away, with the completion time of its last stage. If work is still open, it simply resumes.
• Completing a parked run is refused. Asking to complete a run that is On hold or Cancelled — setting its status to completed through the API, or finishing it — is refused with HTTP 409 and the error instance_not_finishable. Resume it first; an already Completed run stays an idempotent success.
• Moving a task into a stage that already finished reopens that stage. The stage goes back to In progress until the moved task's work is done, so the run does not complete while that task still has required work.

Downloading output as PDF

When a workflow action completes with a text output, a "Download as PDF" button appears in the action card's Output section. Clicking it opens your browser's native print dialog pre-set to the output content — choose "Save as PDF" as the destination to export the result. The PDF holds the document alone: the step's title, its reading time, and the output.

The same button appears on a Document action's Preview (see above). An action that writes its result to the instance knowledge base links to that page under its output: Saved to knowledge base opens it.

Tips:

• In Chrome and Edge, select "Save as PDF" from the Destination dropdown in the print dialog.
• In Firefox, choose "Microsoft Print to PDF" or "Save to PDF" from the printer list.
• In Safari on macOS, click the PDF dropdown in the bottom-left of the print dialog and select "Save as PDF".
• The exported PDF includes only the output content — the surrounding process UI and navigation are hidden automatically.

Related