Step types

A workflow's steps fall into two groups: action steps, which do something, and control-flow steps, which shape the path through the other steps.

Action steps

API call

Configure the URL, HTTP method, query parameters, headers, and body. Any of them can use {{...}} references to earlier steps, and a body that is a single reference to a list or an object is sent as that JSON. Set a timeout, and turn on continue on error if a failed call shouldn't stop the run.

Auth comes from one of two places:

• A Connection — the base URL, credentials and fixed headers are already saved, and the connection's config fields fill in as default path parameters.
• A key entered on the step — bearer, basic, or an API-key header. A step that needs one can create it in place rather than sending you elsewhere first.

A step that signs its request needs its address written out, so data from a trigger or an earlier step can never choose where your key goes; keep references in the path or query. A connection's key only ever goes to that connection's own address.

Any API call step can carry auth, not just the ones started from a catalog entry. A step that declares auth but has none selected is flagged, rather than sending the request unauthenticated and failing at the far end with nothing on the canvas to explain why.

Tool

A Tool step calls one of an installed Wapp's own tools — querying, creating, updating, or deleting records. The editor knows what each returns before you've run it, so the data picker can offer the right fields straight away:

Every one also returns success.

Each record a query returns carries its id, its field values, and when it was created and last updated — createdAt and updatedAt, as ISO dates — so a step can say when something was added, not just list it in order.

What a record contains depends on the collection, so a reference like records[0].company is accepted rather than flagged.

Code

Code steps run sandboxed JavaScript.

The code editor has a soft wrap toggle — remembered for you, since it's a reading preference rather than a property of the step — and an expand button that opens the same editor in a full-size dialog. Completions and the {{...}} picker behave identically inline and expanded.

A code step's output is exactly what its code returns — return { message, total } and later steps read {{steps["My step"].message}}, with nothing wrapped around it. The editor reads that from the return statements before the step has ever run, so later steps can autocomplete against it: it understands literals, variables you declared, .length, and common calls, and lists any key it can't type as unknown rather than dropping it. An output contract you wrote by hand wins; otherwise what a successful test run learned fills in the types the code alone doesn't say.

A Code step supports a timeout and continue on error, and can require human approval before running:

• Set approval to manual (always requires sign-off) or auto (runs immediately unless a condition you define requires review).
• Choose approvers — specific workspace members who can approve — and optionally an escalation: if no approver responds within a set time, it escalates to a different set of members.
• Everyone asked is notified with Approve and Decline, and any of them can answer. An approved run carries on as the automation's owner.
• A decline stops the run at that step. Its history records it as stopped, with the reason, not as a failure.
• A Code step's approval asks every time: an automation's Ask me first switch covers its Wait for approval steps only.

See Approvals.

AI Agent

Model selection defaults to Auto (Cheqq's managed default) or can be pinned to a specific model, including one from your own connected provider key. Configure a prompt/system prompt, a temperature, and a max output token limit. An AI step can optionally return structured output matching a schema you define, or drive a live browser session through the Companion extension for that run. Image-generating AI steps are a separate output mode and can't combine with structured output, browser control, temperature, or token limits.

Choose Video as the output mode to generate a private workspace video. Configure its supported duration, resolution, orientation, and audio setting. The model picker is filtered to admin-approved video models. Previous-step image paths can be used as image-to-video references, and the step returns the active video path plus file metadata for downstream steps. Like Image mode, Video mode cannot combine with structured output, browser control, temperature, or token limits.

Text from outside your workspace

An email, a form, a webhook, a feed or a page the browser read can say anything, including "ignore your instructions". AI steps treat that text as information to work with, never as instructions, whatever model reads it. Records an automation makes from it are remembered as coming from outside too, so an automation those records start works with only the tools its steps declare. Automations you or your schedule start keep their tools.

The same goes for records a step looks up that came from outside, like a reply someone sent or a form a visitor filled in: once an automation has read one, its later AI steps treat what they read as information too.

An AI step that can search the web or use your connected apps counts as reading from outside even on a run where it doesn't, since nothing it says could be told apart. Give a step only the tools it needs under Tools, and what it writes stays your workspace's own.

Instant answers for steps that only pick

An AI step whose only output is a single choice from a list, or a yes/no, can be answered instantly. When Cheqq is sure of the answer it uses it, in well under a second and for less than a full AI call; when it isn't, the step's own model answers as usual. Steps that write prose, read files or use the browser always use their model. Text from outside your workspace, like an inbound email, a webhook, a feed or a page the browser read, is answered the same way, and every AI step treats it as information to work with, never as instructions. When you've set a Security Processor Model, input from an email or a webhook is checked by it first and answered by the step's model. To always use the model, turn off Quick Answers in Settings → Advanced.

Classify

A Classify step sorts something into one of a fixed set of options: an incoming lead into Hot, Warm or Cold, a support request into Billing, Bug or Question, an email into Order, Invoice or Other. Put a Branch after it and each kind of item takes its own path.

Set it up with:

• Input — what to sort, usually a reference such as {{trigger.body}} or {{steps["Read email"].text}}.
• Instructions — how to choose, in your own words: what counts as hot, what to look at first. Optional when the options speak for themselves.
• Options — two to twenty, each with its own label. Add a description to any option whose label alone doesn't say what belongs in it. Drag to reorder.
• Model — the model that answers when Cheqq isn't sure. Leave it on Auto for Cheqq's default.
• Fallback choice — the option to pick when the workspace is out of AI credits, so the run keeps going instead of stopping.

When Cheqq is sure of the answer, the step answers instantly and costs less than an AI call; otherwise its model decides. It treats text from outside your workspace the same way AI steps do, and Quick Answers in Settings → Advanced turns instant answers off.

It outputs:

Route on the choice with a rule such as:

Sort lead · Choice    is    Hot

which reads steps["Sort lead"].choice. Cheqq only answers instantly when it is at least 95% sure, so anything it was less sure of went to the model. To have someone check those, add a path ahead of the others for Sort lead · Answered by is model that leads to a Wait for approval step or a notification. For a stricter bar, route on Sort lead · Confidence is at least 0.99 instead.

Use a Classify step when all that's needed is a label. When a later step reads a reason, a summary or several fields, use an AI Agent step with structured output instead.

MCP tools

Every tool on a connected MCP server appears in the step picker under its provider's group, with a form generated from the tool's own schema — pick the tool, fill the arguments (with {{...}} templating), done. Providers you haven't connected yet show as Available to connect, linking to the integrations catalog.

The generic Call MCP Tool step is the escape hatch: choose any server and tool by hand and pass arguments as JSON. Either way the tool runs with exactly the arguments configured, no model involved. A connection that needs re-authorization fails the step with a reconnect hint rather than running with stale access.

Notification

Choose the channels (in-app, push, email), a category, and recipients. You can pick more than one. A new step starts with in-app and push, so people hear about it on their phone, and each person's own notification settings still decide what reaches them. Email is only sent when you choose it. The body can reference other steps' output, and is rendered as Markdown — links in it are clickable.

Link sets where the notification opens when it is selected. Leave it empty and the notification is read-only; point it at a Wapp, a workflow run, or any URL to give it a destination. It accepts {{...}} expressions, so a step can send someone to the exact thing the run just touched:

/workflows/{{trigger.workflowId}}/runs/{{trigger.workflowRunId}}

Recipients are chosen as workflow members or roles, so one step can notify the person who triggered the run, the workflow's author, or everyone with a given role in the Wapp.

See Notifications for how they are read and acted on.

Send email

Sends as a new message, or threaded as a reply to a specific prior message.

Send Via chooses the transport:

• Cheqq (the default) sends from one of your Mailhook addresses.
• Your SMTP server sends through your own mail server, so the message leaves from your real sending address instead of a cheqq.ai one. Store the host, port and credentials once — they're verified when you save them, so a wrong host or password fails in the form rather than days later inside a run.

SMTP logins live on the Mail servers tab in Integrations.

Track Replies in Cheqq is available on both. It sets the message's Reply-To to a Mailhook address, so recipients see your own address as the sender while replies route back into Cheqq and keep reply-triggered workflows working. Leave it empty and replies go to your own mailbox, where Cheqq never sees them.

The body can be written as Markdown, which is rendered to email-safe HTML at send time — so a step that composes a digest doesn't have to emit HTML by hand.

Sends are metered as workflow step-runs on either transport.

Control-flow steps

For Each and the two Do loops cap out at a maximum iteration count (100 by default) to prevent runaway loops. Do Until ends as soon as its condition comes true. Branch and loop conditions are built from rules — a field, a test, and a value — with a JavaScript expression as an escape hatch; see Conditions.

For Each takes the same dotted {{...}} references the editor writes elsewhere, so {{steps.Fetch.records}} works as a list source. When the iteration cap truncates a longer list, the run says so plainly rather than quietly processing the first hundred.

Wait

A Wait step pauses the run until one of five conditions is met:

• Delay — a fixed duration (up to 30 days).
• Datetime — an absolute date and time.
• Expression — a datetime computed from a prior step's output.
• Event — an external event: a collection change or an incoming webhook.
• Manual — pauses until someone approves or declines it, with the same approvers and escalation options as a Code step's approval. A decline stops the run. It can show the approver exactly what happens if they approve, such as the email that goes out, and it follows the automation's Ask me first switch: with asking off, it goes ahead on its own and the run keeps what it went ahead with. See Ask me first.

Continue with Triggers for what starts a run, or Error handling for retries, atomic mode, and dry runs.