Steps

Steps run top to bottom. Add, remove and reorder them in the builder, and give each an optional name so the run history reads sensibly.

Passing results along

A step can use what an earlier step produced, using a reference:

• {{run.input}}: the input this run was started with
• {{trigger.summary}}: a field from the trigger
• {{steps.summarise.output}}: what the step called summarise produced

Type / in any field to insert one rather than typing it. Getting a step id wrong is a common cause of an empty result.

Running once per item

If you point a step's input at a step whose output is a list, it runs once per item, with {{item}} available inside.

Ten competitors summarised individually rather than in one lump, or every file from a Drive folder processed in turn.

You then choose what happens when one item fails:

• Halt the run: stop everything. Right when the items are parts of one deliverable.
• Continue with other items: skip the bad one and carry on. Right when they are independent, and the run finishes as Completed with issues so you know.

Agent steps

Runs an agent. Two ways to specify it:

Define here. Write instructions and pick tools for this step alone. Good when the job is specific to this workflow and does not exist as an agent.

Use an existing agent. Point at one of your agents and pin a revision, so later edits to that agent do not silently change this workflow. Access is re-checked when the workflow runs, so if you lose access to the agent the step fails rather than running with stale permissions.

Prefer an existing agent when the same job is also done by hand in chat. One definition, maintained once.

You can also set the model, the temperature and pinned collections for the step.

Approval steps

Pauses the run until a person decides. The run sits at Waiting for approval until someone approves or rejects, and rejection ends the run.

Approvers: name specific people, or leave it empty for the owner and editors.

Message: say what you want them to look at. "Check the figures against the dashboard before this goes to the client" is a useful message. "Please approve" is not.

Put one before anything that leaves the building: an email to customers, a file written to a shared drive, a post to a channel.

Condition steps

Checks something and decides whether to carry on.

Source: what to check, usually a reference like {{steps.research.output}}.

Check type, one of two:

Rule compares mechanically: is not empty, is empty, contains, does not contain, equals, greater than, less than. Predictable and free. Use it whenever the question is mechanical.

Ask the model puts the question in plain language: "Does this flag an anomaly?". Use it only when the judgement genuinely needs reading comprehension, since it costs a model call and can answer differently on two similar inputs.

If the check fails, skip to a later step or to the end of the workflow. Skipped steps are marked as skipped in the run, so a quiet week reads as "nothing to report" rather than a failure.

The commonest and most useful condition is simply is not empty on a research step, so the workflow does nothing rather than sending an empty digest.

Action steps

Does one specific thing: sends an email, creates a file, calls a tool from a connected service.

Pick the tool, then fill in what it needs. Any field accepts a reference, so the body of an email can be {{steps.writeup.output}}.

Makes a change is a badge on tools that do something in the world rather than just reading. Treat every one of those as needing an approval step before it, unless you are certain.

Like agent steps, an action can run once per item in a list.

If a tool becomes unavailable (a connector switched off, an MCP server removed) the step tells you and you pick another. It does not silently do nothing.

Validating before you save

The builder checks your steps and flags missing or malformed fields against the specific step. A workflow with errors will not save, which is deliberate: a broken workflow that saves is a broken workflow that runs at 9am on Monday.