Workflows

A workflow runs saved project scripts when something happens (an instrument snapshot, a schedule) or when you start it by hand. You review the draft and enable it. Nothing in CloudSprite — including the assistant — turns a workflow on for you.

Pieces

1. Trigger — for example “this instrument captured a snapshot in project cable-qual,” or a cron expression (the builder shows the next few firing times).
2. Steps — one or more saved scripts, each pinned to a version or “latest,” each with its own config.
3. Enabled toggle — off until you say otherwise.

Chained steps run in order. Step 2 can read datasets step 1 just published. Keep chains short and linear.

Example: flag insertion loss after a snapshot

Goal: every time VNA 182 snapshots into this project, extract S22 and flag traces whose insertion loss exceeds 3 dB.

1. Save extract_s22.py and flag_il_over_3db.py on the project Scripts tab; run each once by hand so you trust them.
2. New workflow: trigger = snapshot from that instrument, filtered to this project.
3. Step 1: extract_s22 (pin the version you tested).
4. Step 2: flag_il_over_3db (reads the extract outputs).
5. Review the draft. Enable when the trigger and pins are right.

Run history shows per-step status, logs, and output datasets.

Assistant drafts

The assistant can propose a workflow (trigger + steps) from a sentence like the example above. You still inspect pins, instrument, and project, then save and enable. A draft that is never enabled does nothing.

What workflows are not

• They are not a replacement for notebook snapshots. Snapshots freeze plots; workflows create new datasets.
• They are not instrument drivers. Capture still happens through the lab agent; the workflow starts after the snapshot exists.
• They are not bulk parameter edits. For “add instrument=182 to lot=15,” use a confirmed bulk edit — see Bulk edits.