Run and monitor workflows

Open the automation workspace

Select Automations in the main navigation. Open an existing workflow or create one from the available action.

Build a workflow

A workflow contains one or more triggers feeding into connected steps on a canvas. Select any node to edit its configuration in the detail panel; available actions depend on your connected integrations and installed Wapps.

Control-flow steps — Branch, For Each, Do While, Do Until, Parallel, Wait — shape the path; a Branch or loop decides using conditions you build from dropdowns. Action steps call a tool, an API, an integration, an AI model, code, or send email. Configure every step's required fields; Run stays disabled with a tooltip listing what's unresolved until you do. See Step types for every step's configuration options, and Expressions for referencing one step's output from another.

AI steps and model selection

An AI step's model field defaults to Auto — Cheqq's in-house default model. Open the dropdown to pin a specific Cheqq-managed model or one from your own connected provider instead.

Configure a trigger

Open a trigger node to configure it in the detail panel. There are six trigger types — Manual, Schedule, Webhook, Email, Collection change, and Browser — see Triggers for the full configuration reference, including webhook signature verification and collection-change conditions.

A workflow can have several triggers at once; each can be renamed, reordered, and paused independently. A workflow always needs at least one trigger — deleting the last one is blocked.

Work the canvas

Undo and redo

⌘Z steps back through the edits you have made this session — structural changes and step configuration alike — and ⌘⇧Z steps forward again. One gesture is one undo step, even where it changed several things at once.

Undo covers the canvas, not the whole workflow. Trigger changes are saved separately and stay out of it, and undo is unavailable while a run is in progress or the canvas is read-only. When the local stack runs out, ⌘Z carries on into version history, so you can keep going back past the start of the session.

Copy, paste, and duplicate

⌘C copies the selected step and ⌘V pastes it — below your selection, or at the end of the chain if there isn't one. ⌘D duplicates in place. A copy keeps the original's configuration and lands connected into the chain, and takes a numbered name — "Send email (copy)", then "(copy 2)" — because two steps sharing a name would make {{steps["Send email"]}} ambiguous.

Copying whole control-flow constructs isn't supported yet — copy applies to single action steps.

Delete

Deleting a step joins the step before it to whatever followed, so the chain stays intact rather than stranding everything downstream.

If other steps read data from the one you're deleting, Cheqq asks first and names them. References are left exactly as written — there is no correct way to rewrite a reference whose target no longer exists — and the steps that read from it carry a warning on the canvas until you fix or remove the reference. Undo restores both the step and the references that pointed at it.

Find a step

⌘F opens a search over every step in the workflow by name and integration. Moving through the results lights each one's path on the canvas behind the palette, so you can see where a match sits before jumping; select one and the canvas zooms to it. A match inside a folded construct unfolds it.

Fold a branch, fork, or loop

A chevron on any Branch, Parallel, or loop head folds its body away, leaving the head and a summary of what's hidden — "2 paths · 15 steps" — with a single edge standing in for everything between it and what follows. The same action is in the step's right-click menu.

Folding only changes what you see. The workflow saves identically folded or open, and what's folded is remembered in your browser, per workflow — it isn't shared with anyone else and takes no undo step.

Auto-arrange and the minimap

Auto-arrange (⌘⇧L, the control cluster, or the canvas menu) puts a graph you have dragged out of shape back the way the editor would have drawn it. Step positions are never part of the saved workflow, so this changes what you see and never what you have — it stays available while a run is in progress or the canvas is read-only.

The minimap is off by default. Turn it on from the control cluster and the choice is remembered in your browser.

Follow a run

While a workflow runs, the canvas moves to keep the running step in view — and frames the whole active front where a Parallel step has several lanes going at once. Pan away and following stops, so you can look wherever you want; bring the running step back into view, or select the follow control, and it resumes. The next run re-arms it.

Keyboard shortcuts

Press ? on the canvas for a sheet listing every shortcut, grouped by what you're doing — it's also in the canvas right-click menu. Each button in the control cluster names itself and its shortcut on hover.

With a step selected, the arrow keys move the selection rather than the viewport: up and down along the chain, left and right across the arms of a branch or the lanes of a fork. Escape clears the selection and hands the arrows back to panning the canvas.

On Windows and Linux, Ctrl stands in for ⌘.

Test and run

• Test Step, in a step's detail panel, runs just that step in isolation — useful while wiring up a new action.
• Dry run, from the toolbar dropdown, executes the workflow but substitutes safe simulated output for steps that would otherwise have a real side effect (like sending an email), so you can preview the path without external effects.
• Run now performs a full, real run.

While a run is in progress the canvas locks — nodes, edges, and step configuration can't be edited — and the toolbar shows Stop instead. Stopping is cooperative: the current step finishes, no further steps start.

If a step fails and Power Mode (continue on error) is on for that step, the run continues and the failed node shows an amber warning badge with a "Last Run Error" card — message, timestamp, and a suggested fix (for example, a Reconnect button on an auth failure). See Error handling for atomic mode and exactly which steps a dry run stubs out.

Read a run

Open View runs from the workflow header, then any run.

A run reads as what happened, in order. Each step appears under the name you gave it, with its icon and how long it took, and steps that ran because a branch chose them are indented under that branch. Where a step's result says something specific, it says it:

Check amount                Branch          516ms
  Amount is at least 5000 — took this path

  Big win notification      Notification     52ms
  Sent "Big win! 🎉"

The header says how the run ended and what set it off — Deal "Kestrel Robotics — paid pilot" was updated, or You ran this by hand. A failed step shows the reason in plain words, where it failed.

See the data under any step opens exactly what that step returned, and the same control under What started it opens what came into the run. Nothing is hidden — it just isn't the first thing you have to read.

Results on the canvas

A step that generates an image or a video shows it on the step itself, on the canvas, as soon as that step finishes — you don't have to wait for the run to end or open the run page. Select the thumbnail to open it full size; Escape closes it.

Steps configured to produce media hold space for the result from the moment the run starts, so a picture arriving doesn't shift the rest of the graph. Steps that produce something else show a one-line summary when the run settles.

Results stay for as long as you're on the page. Reloading clears them, so a result you're looking at is always from the run you just watched — open the run from View runs for a permanent record.

Activate an automation

Activation happens at two levels: the whole workflow (Active/Paused, via the header switch or the workflow card menu) and each trigger individually (a switch at the top of that trigger's detail panel). Pausing the workflow overrides every trigger; pausing one trigger leaves the rest running. Pausing never cancels a run already underway — only future firings.

Browse and restore workflow history

Open History in the workflow editor to browse committed authoring versions. Autosave batches become history entries when their changes are committed, and pending autosave work flushes before Undo or Redo.

• Undo and Redo move the shared workflow history cursor.
• Compare covers the definition, nodes, edges, layout, editable settings, and trigger configuration.
• Restore creates a new, undoable version from an older entry.
• Paid workspaces can name and pin a retained entry as a snapshot.
• Deleted workflows can be recovered from Trash during their retention window.

History changes authoring state only. It never deletes or rewrites completed runs, logs, or execution history. Undo, Redo, and restore preserve the current active or paused state; a trigger reintroduced from older history starts inactive. A restored trashed workflow also starts inactive unless you explicitly choose to resume it.

See History and recovery for collaborative Undo, retention, snapshots, and checkpoint integration.

For failed runs, see Troubleshooting.