Dashboard: Workflows

Per ADR-062, Workflows and Catalog › Registry are the same underlying resource, not two resources that link to each other — a workflow enters the system exclusively through package install; there is no POST /workflows or PUT /workflows/{id} (ADR-060). The Workflows list is a filtered view of installed packages (type=workflow), not an independent CRUD surface.

Workflow List

Route: /workflows (WorkflowList.tsx)

Lists installed workflow-type packages. "New Workflow" routes into the Catalog › Registry install flow (see catalog.md) — there is no create form here.

Workflow Detail

Route: /workflows/:id (WorkflowDetail.tsx)

Shows the workflow's definition (steps, execution modes) and its run history. Each run row links to Run Detail below; "view package" links to the shared Package Detail view.

Workflow Studio

Route: /workflows/:id/studio (WorkflowStudio.tsx)

A ReactFlow-based visual node-graph editor for a workflow's step DAG — five node types (Sequential, Fan Out, Collect, Conditional, Loop), drag/connect editing, undo/redo history, and a live run overlay driven over a WebSocket (RunOverlay.tsx/RunProgressPanel.tsx) that highlights the currently-executing node during a run.

There is no save/persist action. Node editing in Studio is local-only exploration/prototyping against the loaded diagram — useful for visualizing and experimenting with a workflow's shape, but changes don't persist anywhere. Don't expect edits made here to survive a page reload. Authoring a workflow package for real means editing its workflow.json payload directly and publishing it through the Registry (see catalog.md).

The canvas is deliberately full-bleed chrome with no PageHeader/breadcrumb bar, to avoid eating into the ReactFlow viewport.

Run Detail

Route: /workflows/:id/runs/:runId (RunDetail.tsx)

Per-run, per-step drill-down: each step's status, timing, and output, with a step→agent link (resolved from the step's AgentRef) into Agent Detail. An accordion of audit entries for the run links out to the Audit Trail, scoped with ?run_id=.

Suspended/Escalated run states (a stranded write awaiting a downstream mediation decision, or a human-in-the-loop wait state — see object-model.md) are surfaced observationally only — there is no in-console worklist or action to resolve them from here. The human decision arrives via the carrier's own surface (an adjuster/SIU queue, or the carrier's BPM system over MCP), never a console queue — see reference/api/approvals.md.

Related: