Asking a person

Most flows run start to finish on their own. Sometimes, though, a step needs a human: approve this amount, pick one of these options, confirm the extracted field is right, upload the evidence. That’s what the Ask a person step is for — it puts a person in the loop and pauses the flow until they answer.

This page explains what happens while the flow waits, the channels you can reach the person on, and how to keep an answer from getting lost.

The lifecycle

When a flow reaches an Ask a person step, the run doesn’t just block a thread — it is durably paused. Its state is saved, a record of the open question is created, and the run is marked WAITING. It will sit there for as long as it takes — seconds or days — until someone answers. The answer then flows on to later steps as a value.

answer available as {{ label.response }}

Concretely, the answer is exposed to later steps under the step’s label — {{ <label>.response }} (and at the top level as {{ response }}). So an ask labelled approval makes its answer available as {{ approval.response }}. See Template variables for how references work.

What you can ask for

The response type decides which input the person sees and how their answer is stored:

Response type	What the person sees
Free text	A text box
Yes / no	Yes and No buttons
Choice	A dropdown built from the `options` you list
Acknowledge	A single “got it” confirmation button
Integer / Decimal	A number field
Date / Time / Date & time	Native-style pickers, stored as a canonical ISO string
Image / PDF / File	A file upload

Channels — where the question reaches the person

A flow can run anywhere, but the person you’re asking is somewhere specific — at the canvas watching the run, or away from it entirely. The channel is how the question gets to them. You choose it per step; the channels sit on a spectrum from answer right here, now to off-platform:

AT THE CANVAS IN-APP, ASYNC OFF-PLATFORM

Inline Modal Notification Email WhatsApp Slack unanswered ≈90s → promoted

Left → right: increasingly asynchronous — the person gets further from the running flow.

Inline (the default) — the question appears right on the run’s canvas. Best when the person who started the flow is watching it and can answer on the spot.
Modal — a synchronous pop-up on the run’s canvas. Like inline, it’s for someone who’s watching the run and answers on the spot — it just surfaces the question as a dialog rather than a form in the run view. Both on-canvas channels can collect a file answer (see below).
Notification — the bell announces it (“Decision needed →”), and the person answers it from their Inbox — the bell itself never resolves an ask, it’s just the pointer. Best when the person is in Routario but not necessarily at this run — they’ll see it whenever they next look, and the bell pointer clears itself the moment it’s answered, from any surface.
Email / WhatsApp / Slack — the question goes to the person where they already are, off-platform. Best when they don’t live in Routario day to day. They answer from the message itself, and the flow resumes.
Voice (Scout) — a paired Scout device speaks the question out loud and listens for the spoken answer. Best when the person isn’t near a screen at all — a loading bay, a reception desk, a shop floor.

Voice: a spoken conversation with a Scout

Voice is the one channel where the “question” and “answer” are both audio, not text or a form. Picking channel: voice on an ask doesn’t add extra steps to your flow — it’s a single step that, under the hood, does four things in order:

The Scout speaks the question out loud.
It listens for the reply. The device waits for the person to actually start talking and keeps recording through natural pauses, stopping only once they’ve gone quiet for a bit — so it doesn’t cut someone off mid-sentence, and it doesn’t sit there recording silence forever either.
The recording is transcribed to text.
That text is matched against the response type you asked for — a Choice answer like “the green one” is matched to the closest option you listed; an Integer answer like “twenty-three” is parsed to 23. If the answer doesn’t confidently match (mumbled, off-topic, or the wrong shape — someone says a word when you asked for a number), the Scout asks again, reading the valid options back if it’s a Choice. After a couple of failed attempts it gives up and resolves with its best guess rather than leaving the flow stuck forever.

Because a voice ask is a real conversation, it needs a device that can do both halves: Scout device, on the step, picks which paired Scout speaks and listens. Leave it blank to auto-select the first device that holds both the speak and listen capabilities — set it explicitly (e.g. from {{ device.device_id }} looked up earlier) when more than one Scout is paired and it matters which one asks.

An unanswered inline ask is never silently lost

Inline is the friendliest channel when someone’s watching — but what if they step away? Routario covers that. An inline question that goes unanswered past a short grace window (90 seconds by default) is automatically surfaced as a notification — a bell announcement, answered from the Inbox. A quick on-canvas answer produces no bell ping at all; only an ask that’s actually been abandoned gets promoted. Either way, the question resurfaces somewhere the person will find it — it won’t quietly sit unanswered forever.

Escalation: reminders and a fallback person

The 90-second promotion above covers someone who just stepped away for a minute. But what about the manager who’s out sick, or the approver who doesn’t check Routario over the weekend? An ask can sit WAITING for as long as it takes — which is exactly the problem if nobody’s actually looking.

An ask can be configured with an escalation ladder: a re-send, then a hand-off to someone else, each after however long you choose.

A reminder re-sends the same question to the same person a set number of hours (or days) after it was first asked, if it’s still unanswered.
An escalation hands the question to a different person — a fallback approver, a manager, whoever should see it if the original person hasn’t — after a later deadline, still measured from when the question was first asked (not from the reminder).

Both are entirely opt-in. An ask with no reminder or escalation configured behaves exactly as described above — it just waits.

The original person can still answer at any point, even after a reminder or an escalation has fired — nothing is taken away from them, someone else is just also now able to help.

Asking more than one person

A single tier can name more than one person — useful when either of two people can approve, or when you genuinely need both to sign off before the flow moves on:

Either of two people — the flow proceeds the moment anyone named in the tier answers.
Both of two people — the flow waits until everyone named in the tier has answered before moving on. Whoever answers first is recorded; the run only resumes once the last person completes the group.

You can combine these — for example, “either Bob or Carol, and if neither of them answers in time, escalate to both Dave and Erin, who must both sign off.” Each rung of the ladder can have its own group of people and its own combination rule.

If nobody ever answers

Once every reminder and escalation has fired and the ask is still unanswered, you choose what happens next:

Stop the flow with an error — the safest default when the rest of the flow genuinely can’t proceed without an answer.
Move on anyway — the flow continues as if the step had failed gracefully, so a downstream Branch can detect “nobody ever answered” and handle it (send an alert, log it, route to a different process).
Keep waiting (the default) — nothing changes; the ask stays open indefinitely, same as an ask with no escalation configured at all.

Letting the flow keep going: fire-and-continue

By default an ask blocks — nothing downstream runs until it’s answered. For the common “wait for one person” case, that’s exactly right. But sometimes you want to ask several people at once and only join up later — “ask both managers, proceed when both approve.”

Turn on fire-and-continue and the ask dispatches its question and keeps running instead of pausing. The flow continues; later, a Checkpoint (a Wait with conditions) is where the run actually waits for the answer(s). That lets two asks go out together and a single checkpoint join on both.

Because the run doesn’t park on the ask itself, fire-and-continue has three requirements that the editor enforces when you save:

it must have a label (so the checkpoint can refer to its answer),
it must use an off-canvas channel (notification or whatsapp) — the on-canvas inline and modal channels have nowhere to deliver a question once the flow has moved on, and
there must be a downstream Checkpoint that waits on this ask’s answer.

Tell vs ask: Send pop-up

Asking pauses the flow for a two-way exchange. If you only need to show someone a value — no answer required — reach for the Send pop-up step instead. It surfaces a quick, ephemeral readout on the canvas to whoever’s watching the run, and the flow keeps going.

Send pop-up · tell Flow Whoever’s watching shows a value One-way. The run does not wait.

Ask a person · ask Flow Person question answer Two-way. The run pauses until it’s answered.

So: Send pop-up tells, Ask a person asks. The ask’s own modal channel is the two-way version of that on-canvas pop-up — it asks and waits for an answer, where Send pop-up only shows a value and moves on. If the message must persist or reach someone who isn’t watching the run, use a Send notification (or a real ask) instead — a pop-up is ephemeral and shows only to the person currently at the canvas.

Where to go next

Ask a person — full reference — every field, with example values.
Send pop-up — full reference — the one-way readout counterpart.
Checkpoint and Wait — where a fire-and-continue ask is joined back up.
Template variables — how {{ <label>.response }} and friends work.
Scouts: eyes, ears, and a voice in the world — what a Scout device is and how it’s paired, for the Voice channel.
How agents ask before they write — the equivalent mechanism when it’s an agent asking to approve a write, not a flow asking a person a question.