Human in the loop
Some decisions should not be made by an automation on its own. Human in the loop is the mechanism for that: a step pauses mid-run, asks a person a question, and continues with their answer once they have given it.
It is what lets you automate a process end to end while keeping a person on the one part that genuinely needs judgment—approving a publish, choosing between drafts an agent produced, supplying a detail the flow could not work out for itself.
How a step pauses
An AI step can reach a point where it needs something only a person can supply. When it does, three things happen:
- The step stops and the run parks. The node shows an Awaiting Input status on the canvas.
- The question is presented wherever you configured it to be—in a chat channel, or simply on the approvals page.
- Nothing else in the run advances past that point.
When somebody answers, the step resumes from exactly where it stopped, with their answer as part of what it knows, and the flow carries on.
A parked run consumes nothing while it waits. It is not a thread sitting idle or a job spinning; the run's state is stored and picked up again when the answer arrives. This is why a step can wait hours for somebody to come back from lunch without costing anything or being at risk from a restart, and why parking a run is a perfectly ordinary thing to do rather than something to avoid.
Pausing is opt-in, per step
A step does not pause unless you tell it it may. Turn on the step's Human in the Loop setting and choose which channels the question is pushed to. A step without the setting never pauses: the agent has to finish the task on its own, whatever it runs into.
Turning it on does not force a pause either. It grants permission—the step pauses if and when the work actually reaches a point that needs a person, and runs straight through when it does not.
By default the channels you pick also receive the agent's running progress, not only its questions. Turn on Only Notify on Questions to quiet that stream and push only the moments the step actually stops to ask. This is worth doing for an agent that reasons at length before asking, or that usually finishes unaided and would otherwise fill a channel with updates nobody needs. The full progress stays visible in the run's own history either way—the setting only changes what is pushed outward.
Where a request is answered
The Approvals page is the home of every waiting request. It lists every step across every automation that is currently parked on a person, so you do not have to know which automation stopped in order to find and answer it. Each row shows the automation, the run, the step, and how long it has been waiting, and responding opens the answer form.
Look for Approvals in the navigation. It is always available, whatever channels a step was configured with—so a request is never unanswerable because a chat integration was misconfigured or a message was deleted.
Slack and Microsoft Teams can both present a request and take the answer, so a person can respond without leaving the conversation they are already in. The message carries the question and inputs shaped to it—a yes-or-no confirmation, a choice among options, or a small form—and submitting it resumes the run.
Both need a callback configured on the provider's side before an answer can travel back. Until that is done, requests still post to the channel and still park the run correctly; they simply have to be answered on the Approvals page instead of from the message. See Slack and Microsoft Teams for that setup.
Picking no channel is also a valid choice. The request still pauses the flow and is still answerable on the Approvals page—it just does not go looking for anybody.
You can also subscribe to be notified in the CMS whenever a run you care about pauses for input, from your profile's notification settings, scoped to particular automations if you like.
Answering in more than one place
You can push the same request to several channels at once. Whichever one somebody answers in, the others update to show it has been resolved—so two people cannot answer the same question twice, and nobody wastes time on a request that has already been handled.
Waiting does not go on forever
A parked step is bounded by the Awaiting Input Timeout, set in hours on the Nodes tab of the Settings page. A request nobody answers within that window fails the step, and the run then behaves as it would for any other failure—following an error path if one is wired, ending in failure if not.
This timeout is separate from the limits on how long a run may spend working, and deliberately so: the clock that bounds machine time does not tick while a person is deciding. Waiting for somebody is not the same as running away with resources, and the two are bounded independently.
If a request times out, nothing about it was lost—the run's history records the question that was asked, that nobody answered it, and when it expired.