​

Runs and schedules

A run is one execution request for a QuickFlow. A schedule manages recurring requests. Prove a QuickFlow with a manual run before adding recurrence.

​

Manual run

1. Confirm source and destination connections still validate.
2. Confirm the selected cluster is ready or can auto-resume.
3. Start a manual run from the QuickFlow.
4. Open run history and inspect the new run’s state and details.
5. Resolve configuration or capacity failures before retrying.

Run list and detail operations are scoped to the parent QuickFlow, organization, and workspace. Treat a submitted run ID as the handle for that execution; do not infer success from request acceptance alone.

​

Interpret lifecycle state

The exact status values are defined by the generated contract. Operationally, distinguish queued/pending work, active execution, terminal success, terminal failure, and cancellation when present. A cluster transition or worker delay can keep work pending without making the QuickFlow invalid.

​

Schedules

The public schedule surface supports creating, listing, fetching, updating, pausing, resuming, and deleting schedules associated with a QuickFlow.

• Pause stops future launches without deleting the definition.
• Resume re-enables a paused definition.
• Update changes supported schedule configuration for future launches.
• Delete removes recurrence; it does not imply deletion of historical runs.

​

Failure checklist

• QuickFlow and schedule still exist.
• Schedule is active rather than paused.
• Connection credentials and secret references are valid.
• Cluster is ready, startable, and properly sized.
• Source selection and incremental cursor settings remain valid.
• Current identity has permission to the QuickFlow and related resources.

Avoid promising idempotent retries unless the operation contract explicitly supplies an idempotency mechanism.