Loading docs
Understand how workflow records preserve visual design, generated source, route context, run history, and evidence pointers.
A workflow record is the durable unit of quantum work. It owns the visual design, generated source, route context, run history, comments, and evidence references.
Use this reference when an integration needs to import, duplicate, clone, or review a workflow without confusing private workspace state with public proof.
Understand how workflow records preserve visual design, generated source, route context, run history, and evidence pointers.
This page belongs to the API & Evidence section and should be read with the related pages listed at the end.
Use screenshots and notes to explain product behavior without exposing private credentials, admin state, or customer data.

A workflow record should include title, owner, workspace, visual operations, generated code metadata, provider route context, status, timestamps, and evidence references.
Generated source can change when the visual circuit changes. Treat source snapshots used for a run as evidence artifacts rather than mutable draft text.
Cloning public shares or templates should create a new owner-scoped record. It must not carry private provider credentials, billing state, admin notes, or original user secrets.
Imports should validate circuit operations and generated source before a run can be routed.
Learn the product language behind workflows, blocks, generated code, provider routing, runs, evidence, and learning records.
Review generated Qiskit, Cirq, and OpenQASM output beside the visual workflow before routing or exporting.
Understand the public product contract for creating, tracking, exporting, and reviewing quantum workflow runs.