> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/human-handoffs.md). # 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](/build-and-improve/automate/human-handoffs/request-approval.md) — ask an assigned person to choose from defined options. * [Request Input](/build-and-improve/automate/human-handoffs/request-input-page.md) — ask an assigned person to provide information through a configured form. ![Request Decision and Request Input side by side in the Workflow builder, showing their different configuration and output shapes.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-0c7afc3659deef7c3a9aa6c4b4fbca2bfba04f2e%2Frequest-decision-input-config.png?alt=media) 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](/run-operations/request-inbox.md) 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](/run-operations/agent.md)'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](/understand-lleverage/readme/requests-exceptions-and-human-attention.md) for the conceptual distinction and the operator-facing [Requests](/run-operations/request-inbox.md) 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](/administer-and-govern/governance/human-boundaries-and-operational-ownership.md). ## 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](/build-and-improve/automate/test-and-publish/error-handling-and-validation.md). ## 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. ## Related documentation * Configure a decision → [Request Decision](/build-and-improve/automate/human-handoffs/request-approval.md) * Collect structured input → [Request Input](/build-and-improve/automate/human-handoffs/request-input-page.md) * See the operator experience → [Requests](/run-operations/request-inbox.md) * Inspect how the handoff behaved in execution → [Monitoring](/build-and-improve/monitoring.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lleverage.ai/build-and-improve/automate/human-handoffs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.