Tasks for people

A Human task node pauses a scenario and waits for a person to decide — approve or reject an invoice, confirm a refund, pick one of several options — then continues down the branch matching whatever was chosen, with the resolver’s own answer available as a typed value inside that branch. It’s the same shape as a Telegram question (send, wait, branch on the pressed button) with no messenger involved: the “message” is a row on a page inside the product itself.

Fields

• Title and Description — the one-line summary shown in the task list, and a longer, Markdown-formatted explanation (what to decide, links, amounts) shown on the task itself.

• Context — an optional expression evaluating to any structured value (the order being approved, the record under review), shown as a read-only block on the task — never editable by the person resolving it.

• Attachments — an optional list of files, shown as download links.

• Timeout — an optional duration (48h, 3d). Leave it blank and the scenario waits forever; set it and the node takes a fixed, automatic Timeout branch if nobody resolves the task in time (see below).

Options and typed answers

Each option is a button the person sees on the task — Approve/Reject by default, freely renamed or added to, exactly like a Telegram question’s own buttons. What makes a human task’s options different from a plain branch is that each one can also collect a typed value from the person resolving it:

• Void — a bare button, nothing else to fill in.

• Text — a text box (a rejection reason, a corrected value).

• Number — a numeric input.

• Boolean — a checkbox/switch.

There’s no separate “comment” field: a Reject option with a Text answer and a prompt of “Reason” is the comment field. Inside each option’s branch, two variables are in scope: task (who resolved it and when) and, for any option that isn’t Void, data — typed exactly as that option’s chosen answer type.

The Timeout branch

Setting a Timeout adds one more branch to the node automatically — fixed, always last, not deletable or renamable. If nobody resolves the task within the configured duration, the scenario takes that branch instead (the task itself is marked Expired on the Tasks page) and continues from there — useful for “escalate if nobody responds in a day” flows. A scenario that’s stopped or rebuilt while a task is still open closes it too (as Cancelled), so a task never sits open forever pointing at a run that no longer exists. Clearing the Timeout removes the branch again — unless it already contains icons, in which case it stays on the canvas (never deleted silently) but is no longer compiled.

The Tasks page

Every open (and past) task lives on a Tasks page — a sibling of the Runs page, reached from the project list or, filtered to just that scenario, from a Tasks tab inside the editor. A task is visible only to the owner of the project that created it — there is no assignee list, no external link and no administrator override in this version; the project owner is who builds and tests the flow, so it’s also who resolves what it’s waiting on. Opening a task shows its description, context, attachments, and one button per option — with the typed input next to it when the option collects a value.

Dev and production

A task created while developing a scenario (a “dev” run) is a real row too, resolved from the same Tasks page — this is how you test an approval flow: build it, run it, and approve/reject it yourself from the workspace’s Tasks tab. A production task survives a redeploy, since a published run keeps executing on its own pinned version regardless of what gets published next; resolving it reaches that exact run.

Telegram questions can time out too

A Telegram question node gained the same Timeout field in the same pass — set it and an unanswered inline-keyboard question takes its own automatic timeout branch, removing the buttons and sending a short “this question has expired” message instead of waiting forever.