Workflows

A trigger plus ordered steps, run with nobody in the room.

A workflow is a trigger and an ordered list of steps that Gus writes for you. It runs unattended.

Workflows, before any have been written.

A step

One ES module exporting run(ctx), executed in its own sandbox. What is on ctx is deliberately small:

On ctx	What it is
ctx.input	The previous step’s return value, or the webhook body for the first step
ctx.gus(prompt)	Asks a fresh Gus and returns the reply
ctx.say(text)	The only way a run posts to its channel
ctx.tables	Reads and writes this team’s tables

Nothing else. A step’s return value is passed to the next step and posted nowhere, so if a run should report something, it has to say so.

Versions and runs

Publishing takes an immutable snapshot of the steps, and a run records which version it executed. Editing a workflow mid-run cannot change what a recovery replays. Renaming does not mint a version; changed steps do.

The run id is the occurrence: the cron slot, the sender’s delivery id, or a fresh id for Run now. That one identity buys both occurrence dedupe and one-live-run-at-a-time, without a second mechanism.

Who a run acts as

A workflow step reaches tables and connections as the member who created the workflow, never as the bare organisation. A workflow created in a DM is private to its creator by default; everything else belongs to the team. Admins and owners see both.

A workflow that needs a credential it does not have pauses with a reason rather than failing. Fix the connection and it carries on.