Run and monitor workflows

Open the automation workspace

Select Automations in the main navigation. The list puts what needs you first:

• Needs attention — a run waiting on your answer, an automation that's on but has every trigger switched off (marked Triggers off), or one whose last run failed.
• On and Off — everything else, by whether it's switched on.

Each card says how the automation starts in plain words — "Record change", "Every Monday at 8:00 AM, UTC" — and when it next runs or how its last run went. Use the search box to find one by name. Selecting Run now on an automation that's off offers to turn it on. An automation with an approval step also says whether it Asks you first or Runs on its own; see Ask me first.

Pin an automation to the sidebar

Select the pin in the editor header (Pin to the sidebar) to keep an automation under Pinned automations in the sidebar, one click from anywhere. Select it again to unpin.

Create an automation

Inside a Wapp, Create Workflow goes straight to the name, so the automation starts out attached to that Wapp.

An automation with no steps shows Ask Cheqq to build it at the foot of its canvas — it opens the editor's chat, ready for you to describe what you want.

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.

Until a workflow has steps, its first trigger shows an Add step button that opens the step catalog. After that, the last step of every path keeps its + in view, so you can always see how to carry on — on a phone too. Add trigger sits right beside the last trigger.

Edits save as you go. Leaving the editor — with a link, or with the browser's Back button — saves anything still pending. A brand-new workflow with no steps is kept as a draft if you press Back; following a link away from it asks Leave workflow? first.

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.

An AI step that only has to pick an option or answer yes or no is answered instantly when Cheqq is sure, and by its model otherwise. To sort items into a few options, such as incoming leads or requests, add a Classify step and branch on its choice. See Classify.

Keep running when credits run out

An AI step can carry a fallback: Fallback text for a step that writes prose, or Fallback values for one that produces fields. When the workspace is out of AI credits, the step uses its fallback and the run carries on. The run reads Ran without AI, its page lists the Steps that ran without AI, and the workspace owner is told once a month. When Cheqq builds an automation for you, it writes a fallback for each AI step. A step with no fallback stops the run there, and picture and video steps have none.

Ask the agent to build it

Describe the automation in the editor's chat, or in the main chat, and the workflow agent builds it. In the main chat you watch the canvas take shape beside the conversation, and can zoom, fit it to the pane, or auto-arrange it as it grows; see Follow what a thread builds.

The agent keeps judgement — scoring a lead, qualifying an enquiry, deciding what's urgent — on an AI step, and scores with code only when you give it a rule to apply.

When the draft is ready, the agent saves it — creating the workflow, or writing into the one you have open — and tells you what it did. Every version is kept in the workflow's history, so an agent-made save is as easy to step back from as your own. If you'd rather look before anything is saved, say so and the agent stops at a review card instead.

The agent can also:

• Create the webhook endpoint a webhook trigger needs, and bind the trigger to it. It counts against your plan's endpoint allowance the same way the form does, and the endpoint's URL and secret are never shown to the model — copy them from the trigger's detail panel.
• Delete a workflow, after asking you on an approval card.
• Test the draft before it's saved — see Ask the agent to test it.

A long build runs as a task that carries on if you close the tab; see Work that keeps going without you.

Configure a trigger

Open a trigger node to configure it in the detail panel. There are six trigger types — Manual, Schedule, Webhook, Email, Record change, and Browser — see Triggers for the full configuration reference, including webhook signature verification and record-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.

Editing a paused trigger keeps it paused — changing a schedule's time never quietly switches it on. Only the trigger's own switch does that. Changing a trigger's type asks first if it would lose its schedule, webhook, email address, collection, or inputs.

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. On an email step it offers Send me a test, which runs the step for real with the recipient rerouted to your own address.
• Dry run, from the toolbar dropdown, executes the workflow but substitutes safe simulated output for every step that would otherwise have a real side effect (like sending an email, or writing records into a collection), so you can preview the path without external effects.
• Run now performs a full, real run.

Ask the agent to test it

The workflow agent can test what it built — including a draft you haven't saved yet — from the editor chat. Ask it to test the workflow and it runs one, then reports each step's output, which steps were simulated, and every {{...}} reference that resolved to nothing.

A test run is the middle ground between a dry run and the real thing. AI steps, reads, and GET requests run for real, so you find out whether a triage workflow actually triages. Anything that changes something is simulated and records what it would have sent:

• Emails and notifications
• Non-GET API calls, integration actions, and MCP actions
• Wapp actions that write records

A test of an AI-heavy workflow can take minutes. If it outlives the wait, the agent is given the run's id and reads the result back later rather than starting a second 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 to see its run history. If the runs can't load, you get the error with Try again, not an empty list. Runs are grouped by day with the time of each, and every skipped or failed run says why in plain words. A string of identical skips folds into one row. Filter to Failed to see only what went wrong — the filter is still there when you come back from a run — and select Load older runs to reach further back.

Open any run and it reads as what happened, in order, down a rail: a status mark, the step's name, what it did, and how long it took. Steps that ran because a branch chose them sit under that branch. Where a step's result says something specific, it says it — how long a wait held, how many records a query found, how many times a loop ran:

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

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

An AI step's line says what it found in plain words, such as Summary: A coffee roaster wants….

The header says how the run ended and what set it off: Deal "Kestrel Robotics — paid pilot" was updated, You ran this by hand, Your Book a table App sent it when one of your Apps started it, You ran it now when you used Run now on a scheduled automation, or You ran it again for a replay. A failed step keeps a tinted card with its whole error, where it failed, and the run offers Fix it with Cheqq: the editor's chat opens with the failure already written out, ready for you to add what you know and send.

A loop folds into a single row. Show 4 passes opens one line per pass, and each pass opens onto the steps it ran. A fold that hides a failure starts open, so a problem is never tucked away.

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.

Step runs and waiting your turn

Every run counts once toward the month's step runs, however it starts: by hand, on a schedule, from an email, a webhook or a record change, from the agent, the Companion or the phone. Dry runs don't count.

At the limit, a run you start yourself stops and shows what your plan offers (See plans). Scheduled and event runs wait, and start on their own when step runs are back, on the 1st or when you upgrade. Repeat firings of a schedule fold into one, and the owner is told once.

Runs take turns fairly. A run that can't start yet reads Waiting for step runs or Queued behind other runs. Where Retry isn't offered, Run it again once step runs are back takes its place. The run's user, the workflow's editors and workspace admins can Stop, Pause, Unpause and Retry it.

Control a run in progress

Pause, Unpause, Retry failed steps, Stop, and Replay are on the run page as well as the workflow card. Each confirms what it did — several of them change nothing visible until the worker catches up, so without a confirmation it isn't obvious the button worked. Deciding an approval from the run page confirms the decision too, and says so if the run has already moved on and the decision can no longer be applied.

Approvals

A Code step or a manual Wait can be set to need someone's approval before it goes on. The run pauses there and asks the people the step names as Approvers — and, if nobody answers in time, the people under Escalate to. On the canvas, a manual Wait reads Wait for approval. The business systems put one before the messages they send to customers, apart from a few routine reminders.

• They're notified. Each person asked gets a notification with Approve and Decline, including for code approvals and when an approval escalates. See Notifications.
• They see what they're saying yes to. When the step says what goes out, as every approval in a business system does, the run page shows it in full under What happens if you approve: for an email, who it's to, the subject and every word. The notification carries the start of it. Otherwise the run page shows what the step before it produced.
• Anyone asked can answer, from the notification or the run page. The run then carries on as the automation's owner — approving lends it a yes, not your accounts.
• Declining stops the run at that step, whatever kind of step it is. Its history shows it as stopped, with the reason, rather than as a failure.
• Everyone else sees who it's waiting on — "Waiting for Alice to approve it" — instead of buttons they couldn't use.

Once someone answers, everyone else's notification says who did and what happened. An approval inside a branch or a loop works the same way.

Ask me first

Every automation with a Wait for approval step starts on Ask me first: each run waits for a yes at that step. When what it does is what you'd have done anyway, let it run on its own instead.

• The switch. The automation's header reads Asks you first or Runs on its own. Select it for the Ask me first switch, and to see who last changed it and when. In the Automations list, the same label opens it. Turning asking off checks with you first.
• Approve and stop asking sits beside Approve on the run page, and under … on the notification. It checks with you, then approves this one and turns asking off.
• The offer. Once you've approved the last 3 as drafted, the approval asks whether to Let it run on its own. Keep asking puts the offer away until you've approved 5 more. A decline starts the count again, and so does turning asking back on.

Running on its own, an approval goes ahead as soon as a run reaches it, with no pause and no notification. The run marks the step Went ahead on its own, without asking, and keeps What it went ahead with, with who turned asking off and when. Turn Ask me first back on and the next run that reaches the step asks again. A run that was already waiting when you turned it off stays yours to answer.

Only people who can edit the automation can change whether it asks; everyone else sees which way it's set. Your choice stays through template updates, and a copy of the automation starts out asking.

An approval that goes ahead on its own isn't anyone's yes, so email sent after it counts toward the hourly limit on email nobody approved.

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.

Who can change an automation

An automation can ask for a role of whoever changes it, like a template that asks for its owner. Your role on it is the highest you hold: as the person who made it (its owner), as someone it's shared with, as a member of a Wapp it's part of, or as an admin or owner of the workspace. At that role or above you can change it; with no role asked, editors can, as always.

Below that role you can still open it, run it and test it, but its steps, its triggers and its schedule stay as they are: you can't edit, add, remove or reorder them, change its settings or whether other agents can reach it, pause or resume it, or move it to Trash or restore it from there. The editor opens read-only and says which role can, and the automations list leaves out its switch and Move to Trash, on the web and on your phone. Renaming it, changing its description, and answering an approval or stopping a run you may steer, work as before.

Changing when an automation runs and changing what it does are two different things. Its steps can only be saved by the person who made it and by people it's shared with as editors. If you reach it only through a Wapp it's part of, as a member or as a workspace admin, you can still switch it on and off, set or pause its schedule, add and edit its triggers, rename it, and move it to Trash or restore it, as long as you're at the role it asks for. Its steps open read-only for you and say so.

Runs that wait instead of failing

A run needing the Companion extension doesn't fail when the machine running it is asleep — it parks, and starts on its own when that machine comes back. Repeat firings coalesce onto the run already waiting, so six missed two-hourly sweeps produce one sweep on your return rather than six.

A run that never started because your machine was away shows in the run history in grey, with the reason, and a string of them folds into one row. If a workflow is skipped three times in a row, Cheqq also notifies you, so a schedule that has stopped coinciding with your machine being awake doesn't go unnoticed. See the Companion extension guide for presence and active hours.

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.