Human handoffs
Add deliberate human decisions or input to a running Workflow without confusing them with Agent conversation.
Use a human handoff when a Workflow reaches a decision or missing piece of information that should not be guessed or executed without a person.
The current builder exposes two human-handoff actions:
Request Decision — ask an assigned person to choose from defined options.
Request Input — ask an assigned person to provide information through a configured form.
A Request Decision produces one output path per option, so the canvas can branch on the person's answer. A Request Input collects configured form data and continues on one output path. Both remain explicit Workflow pauses rather than Agent conversation.
In a live Workflow, either action pauses execution, creates a Pending item in Requests and stores the execution state needed to resume. When an authorised user completes the Request, the Workflow resumes from that saved point.
Requests are Workflow handoffs
Request items are created by Workflows. They are separate from the Agent's own human-interaction mechanisms. The Agent can ask a question in a session or require approval for an action without creating a Request item.
See Requests, exceptions and human attention for the conceptual distinction and the operator-facing Requests page for what the assigned person sees and does.
Assignment is part of the boundary
A live Request must be assigned. The current Request nodes expose user assignment in the builder, and the system verifies that the person completing the Request is authorised for that assignment.
The exact wording, decision options, form fields, assignee and point in the process are specific to the Workflow your organisation has configured.
For the wider ownership question — who should remain accountable for which decisions — see Human boundaries and operational ownership.
Requests pause, they do not retry
A Request is a pause in the execution path, not an error. Node retry settings do not re-issue a Request. If the same Request node is encountered again while an identical pending Request already exists, Lleverage reuses that pending handoff rather than intentionally creating duplicate work.
Completed Requests can be reopened in supported cases to replay from that point. Reopen the latest completed Request in a reopen chain; earlier superseded ancestors cannot be reopened independently.
For retry and failure behaviour outside human handoffs, see Error handling and validation.
SLA fields are informational today
A Request can record priority and an SLA deadline. Today that deadline can be used as Request data for sorting and filtering, but Lleverage does not automatically escalate Requests or transition them to at-risk/overdue states. Build any required escalation behaviour explicitly rather than assuming the SLA field enforces it.
Where to go next
Configure a decision → Request Decision
Collect structured input → Request Input
See the operator experience → Requests
Inspect how the handoff behaved in execution → Monitoring
Last updated
Was this helpful?