Loading docs
Run & Route
Run Workflows
Understand run feedback, simulator and hardware execution paths, queue context, and safe retry behavior.
Updated May 26, 2026QFlow StudioNormal userTeacher
Running a workflow should be explicit. The user should know which workflow was submitted, which route was selected, and where evidence will appear.
Treat simulator and hardware runs differently in notes. Simulator runs are useful for fast iteration; hardware runs should include provider and queue context.
Purpose
Understand run feedback, simulator and hardware execution paths, queue context, and safe retry behavior.
Where it fits
This page belongs to the Run & Route section and should be read with the related pages listed at the end.
Review boundary
Use screenshots and notes to explain product behavior without exposing private credentials, admin state, or customer data.
Before you run
Confirm the canvas, generated code, provider selection, and analysis state. If a user cannot explain what will run, pause and inspect the workflow first.
For team workflows, record the success criteria before execution. That makes the result easier to interpret.
Canvas reviewed
Code reviewed
Provider selected
Criteria stated
After you run
Check immediate feedback and then return to run history. The run record should carry status, artifacts, and evidence context.
If a run fails, keep the failed record. It is often useful for debugging provider readiness, circuit constraints, and retry decisions.
Next pages
Results & evidence
Use run history, evidence packets, certificates, and approved shares without exposing private workspace data.
Providers
Select quantum providers, inspect hardware fit, and keep credentials private while routing workflows.
Observatory
Use observability surfaces to monitor provider health, workflow readiness, hardware setup, and operational signals.